Except it does all the time. There are innumerable differences between the OSX, BSD, GNU, and other versions of common command line tools. There are plenty of cases where `jq` will or will not be available. Finally there are differences in how `/bin/sh` will interpret things (which there shouldn't be) depending upon underlying shell is running ksh, zsh, bash, dash, etc.

> There are plenty of cases where `jq` will or will not be available.

Sure. The argument is that it's a lot easier for the user of the program to read an error message that says "jq is required. Run apt-get install jq or homebrew install jq" than to fuck around with the python or ruby ecosystem, especially if they don't work in those languages.

> Finally there are differences in how `/bin/sh` will interpret things (which there shouldn't be) depending upon underlying shell is running ksh, zsh, bash, dash

Do you have an example of code that is written to the POSIX standard of shell that runs differently? I only write POSIX shell, and use https://github.com/koalaman/shellcheck to verify that to prevent that exact thing.

And if you cannot install jq because you're not root, you can still wget it somewhere, it's a static binary.

It's not a static binary, at least on my Mac. It dynamically links against Oniguruma.

I generally agree with your sentiment here, but be careful with assuming bash==bash

There are differences between versions. I can't even remember what they are off the top of my head like I used to, which makes them all the more aggravating to discover again.

But I would recommend sticking to a subset of bash, not any of the new fancy features like 'globstar' which allows recursively globbing.

There are tools to manage these kinds of tests, like bashenv. But you're in the same problem scope at that point.

I much agree with the sister comment and I write my shells for /bin/sh also. There is this wonderful tool called ShellCheck ( https://www.shellcheck.net/ ) that checks that your script is actually POSIX-compliant if it starts with #!/bin/sh

That's why I said "Posix shell" and not bash.

POSIX shell is miserable for programming anything beyond a couple lines. It doesn't even have arrays[1], so you have no available container types within the interpreter itself.

[1] Well, it has $@, which you can use as a general-purpose array with some hacks[2], but that's no way to live.

[2] http://www.etalabs.net/sh_tricks.html

I don't think it's too unreasonable to assume that you'll be able to find bash anywhere you'd find a general purpose python installation and it has plenty of niceties.

But even the nicest shell doesn't solve the dependency problem like statically compiled programs. If I could take my currently running Python code and produce some artifact that would run with nothing other than the python binary I think we'd be in a much better place.

Ohh apparently all I've needed in my life is zipapps.

Agreed that Bash is (relatively) fine, although error prone. My comment was about POSIX shell, which has none of the features (arrays, [[ instead of [, etc.) that make programming tolerable in Bash.

One drawback is that if you want your Bash script to work on macOS, you need to restrict yourself to features that exist on version 3.2 (from 2006) because that's the latest version that will ever be included on macOS by default.

> If I could take my currently running Python code and produce some artifact that would run with nothing other than the python binary I think we'd be in a much better place.

See my other comment: https://news.ycombinator.com/item?id=23338316

That's a matter of opinion. I don't find using "$@" to be a big deal in practice.

Let me put it like this: I'm a programmer. I don't mind making programming a bit harder for myself if it means that I get to avoid a lot of the non-programing minutia that's part of a modern interpreted environment.

Also, if you're willing to take a dependency on jq, the issue goes away completely.