If you are a developer, chances are you have had to work with Windows before. If this is the case, I'm sorry for your loss, and I'm also sorry to say there's little I can do about it. Where I am currently employed, while we primarily use platform-agnostic web technology and the (now) multiplatform .NET corework 69.
Back to complaining: even though our tech stack could be platform-independent, I am forced to use Windows for up to five days a week. This gives me great insight into all of its shortcomings which crop up while doing serious development work. Not the least of which: running any kind of script pops up this annoying, ugly black box, cmd.exe: the glue between MS-DOS and Windows 95.
Shells and terminals
On non-toy operating systems, there is a distinction between the shell and the terminal: a shell is used to interface with programs and the kernel, while the terminal is used to display the in- and output streams from said shell. As I alluded to in the title: on Windows, these are both the same cmd.exe, which handles both the execution and the in- and output. This also means when a program executes an external script, it will give you a pretty little command prompt.
Bandages
Of course, there are situations where you would not want a popup to appear. If you are running startup scripts, then you will probably be annoyed by the black boxes which appear on boot every time. Sometimes they don't even close by themselves! Thankfully, helpful users on StackOverflow have solutions for this: instead of running the script on startup, simply run a shortcut to it, and set the shortcut property "Start minimized". Now your command prompt will be minimized on startup!
If that's not really your thing, you can also use some untrustworthy shareware to:
- Convert your .bat to .exe (not guaranteed to work)
- Wrap your .bat in a VBA script
- Call your script from another script which uses one of the sixteen inconsistent ways to prevent the window from showing up. Then, close the window from the first script, and the second script will continue running!
Painkillers
The only actual solution I've found acceptable over the years was a little tool which, if I remember correctly, was called "run.exe" and produced by the same people behind XMing, the Windows X server implementation, which while cool, was more of a proof of concept (and still is). It would simply take the arguments and run those in an invisible shell. That means it could be invoked from the command prompt, run window, scripts and even shortcuts! I can't find it right now, but this isn't really an issue anymore: the scripts in our company repository are linked to cmd.exe and I don't get paid enough to bother with them. In my personal life, I have graduated to an operating system that respects me.
You might notice this is more of a rant than a well-thought-out blog post, but I'm trying to get into the habit of writing more and about more topics. Look forward to more unhinged thoughts and idiotic takes.