What kind of advice is that? Powershell script is so far off from bash/zsh, there's no good reason to convert everyone. Last time I tried writing Powershell script, it was so verbose and cryptic it wasn't funny.

Powershell has been around for quite a while now, but only recently could you rely on it being installed on Windows systems, let alone be available on Linux. Maybe in another decade, but if you are targeting Unix-like systems bash is probably still your safest bet for portable, interpreted code. Python2 is a close second.

POSIX sh is your safest bet for portable, interpreted code.

What percent of Unices come with Powershell today? I can write my code in bash and forget about it. Or if I'm supporting less systems (most linux + macOS + most modern Unices) I can write my code in perl or python. Powershell? Thanks but no thanks.

> I can write my code in bash and forget about it.

In practice, this approach often results in code that works only on Linux, or on Linux and macOS. I especially hate it when people shove #!/bin/bash as a shebang, and doubly so when it's in scripts that are a part of some npm package.

(On BSDs, Bash is not installed out of the box, and when it is installed, it's not in /bin, since it's not in the base system.)

Still, though, that's a good reason to stick to the original Bourne shell. Powershell, whatever its advantages may be, simply has too heavy dependencies on Linux, since you're dragging in CLR. At that point, like you said, might as well just use Perl or Python for scripting.

> I especially hate it when people shove #!/bin/bash as a shebang

It really ought to be `#!/usr/bin/env bash` , if you're writing a bash script. That'll solve the location problem.

Otherwise, if it's a bash script, you can't get around needing bash on your system (although a great many bash scripts are actually "sh" shell scripts that just happen to specify bash because people are used to that sort of thing).

I think this is a good point but, there is an implicit but well known notion that if you write bash and care about platform coverage, you just write bourne shell. I didn't explicitly write it, but I assumed I would write bourne shell, and whatever shell in random Unix will be able to handle it as well as bash in linux||macOS. As a python lover, I simply can't find one reason to use any other scripting language other than python as long as I accept poor performance and dependencies. I can't see what problem Powershell is supposed to solve.

    #!/bin/sh

Leave bash out of it tbh. In practice that will often end up being bash, but sometimes it won't be an in those cases you'll have yourself covered. Test it with busybox's sh or with dash, just to make sure.

I disagree. I have seen developpers trying to write posix conformant scripts but only testing on bash on redhat. When deploying on ubuntu, /bin/sh was dash and the script did not work. I think people shall use #!/bin/bash until their script has been really tested using dash or busybox. If they do not want to do this additional test work, they should never use #!/bin/sh

It's really not that difficult to avoid bashisms if you get yourself into the habit now, rather than later.

> there is an implicit but well known notion

I wish it was well known. There are many people who don't even realize that Bash and Bourne shell are two different things. From there they assume that if their system runs it correctly, then it's portable.

"#!/usr/bin/env bash" is the right way to do it, but "#!/bin/bash" is so common that I'd just symlink it there if it's not already present. Any reason why these OSes don't do it automatically?

For FreeBSD, for example, `/usr/bin` is reserved for core system binaries only; whatever is installed from ports ends up in `/usr/local/bin`, and the shell bundled with the system is tcsh, not bash.

I'm writing a powershell script at the moment. Why did I chose it? I didn't - it's the only thing guaranteed to be on Windows (realistically).

The problem with powershell as a scripting language, is it's designed to also be used as a shell. Which means, literals can be strings, function parameters are not separated, etc. It reminds me of Tcl in the 90s.

I really like what the powershell environment provides (like cmdlets, .NET) - but the language itself is dismal.

I would have preferred to have seen an existing scripting language, with .NET bindings added to it... the "NIH syndrome".

I've spent a non-trivial amount of time trying to work out how to do in Powershell what in bash would be:

program | tee filename.txt &

It's also too verbose and needs too much shift for me to comfortably use as a shell. So why not just use a 'real' language if I'm going to write a script?