That's why Perl is my go-to choice for glue scripts. It's almost always installed by default, it has stayed consistent for decades without any breaking changes, its regex support is by far the best around, and its almost as good as the shell at gluing commands together.

I'm less likely to have Perl installed than Python on Windows, where I sometimes want my scripts to run as well.

It's also unlikely you have Python installed on Windows though, and there's a non-insignificant change that's an old or random version (probably even Python 2). You can't rely on anything on Windows, so you're definitely going to also install a runtime from Chocolatey or similar.

> That's why Perl is my go-to choice for glue scripts. It's almost always installed by default

My first thought was related to this as well: Perl is _always_ installed, and based on Python's popularity (compared to Perl, at least), I'd assume that Python also was installed by default?

That's an honest question, btw: I use Perl quite a lot, Python not so much (at all). :)

Assuming Python or Perl are installed by default in any server is an invite to a world of pain. At least that's my anecdotal experience.

I've seen instances of some Unix systems not having Perl installed, but that's very rare. Basically everything directly or indirectly depends on Perl, so you really have to run your scripts on a minimal install of RHEL of FreeBSD with 0 ports in order to get into such a situation.

And for that situation you can always break out http://p3rl.org/App::staticperl.

Plus of course if you want to use (pure perl) cpan dependencies I wrote http://p3rl.org/App::FatPacker and http://p3rl.org/Object::Remote to make that easier.

> And for that situation you can always break out http://p3rl.org/App::staticperl.

Why do you link to p3rl.org? And, more importantly, why do you link to something that doesn't exist?

Many container base images won't have perl by default (e.g: alpine).

For servers it's less common, but enterprise systems never cease to amuse me.

Most container base images are often so barebone you can't really count on them containing anything. For instance, on an Alpine image you can't count on bash.

Why?

JS is marginally better than Python for this, because tools for runtime and package version management are better for Node than for Python (proper lockfiles, local package folders, npm bundled with Node for installation, etc.).

Still, zx isn't as nice as Ruby, which has backticks for calling shell as part of the language. So, you don't have to have a separate package installed, just the ruby runtine.

But Perl is even better! Just like Ruby, it comes with backtick shell execution build-in, but unlike Ruby Perl is ubiquitous and is pretty strict about backward compatibility. So, your scripts will just run on all machines you have, no matter what distro you use and how old the machine is (within reason).

Zx seems[1] to take advantage of the way template literals work in JS to do proper shell escaping of the parameters to prevent command injection. Is that handled by the Ruby and Perl backtick syntax as well?

[1] https://github.com/google/zx/blob/3.0.0/test.mjs#L30-L33

Luckily today you can side step many of these issues. You can compile a copy of python + modules + pex into a single file with some open source tooling and get a flat file you just need to copy to your hosts.

Bash just sort happened to be the lowest common denominator in most unix style environments. Because it just sorta ended up being the default. Unix ended up being this different thing where each distro seems to be kind of unique. Then on top of that they are very easy to customize. So while one distro you can assume a particular python level the next disto python is totally optional. Mix in containers and docker images and you have a new level of 'what may or may not be there'. Ah but you may say 'oh just use tech XYZ' that may or may not have the exact same issue as using python in its place. So either 'deal with it' and install what is needed and keep it up to date. Or 'play the LCD game' you use only the bare min and hope you can build something useful enough in bash when another lang may be more appropriate.

I thought that was sh (i.e. bourne shell). As far as i remember bash is not the default shell on a lot of unices.

My understanding is that sh is a specification, not an implementation.

Most images will either have bash or ash installed. ash, being lightweight, is the choice of alpine and related distros.

This is a bit of a Linux specific view of the universe. Yes posix has a standard for how sh should work. But there were specific implementations of sh, and you would get those on commercial Unix or *BSD.

Later shells came in and filled some gaps. OpenBSD still has ksh by default. Linux distros had bash as their /bin/sh.

I didn't know that. Thank you for the explanation!