Hacker News Reader

Comment by luckydude | Hacker News Reader

+1 for the parts that are portable to Bourne shell/ksh/zsh.

-1000 for the parts that are specific to Bash. Stuff like that has been huge pain in my ass over the years. Some clever programmer uses some bash-ism and the build breaks on some ancient hardware that doesn't have bash.

I realize my complaint sounds like Henry Spencer's Ten Commandments and perhaps it feels outdated but trust me, you don't want to wade into thousands of lines of shell to track down why something doesn't work on the stupid AIX box.

View on HN

>Stuff like that has been huge pain in my ass over the years. Some clever programmer uses some bash-ism and the build breaks on some ancient hardware that doesn't have bash.

Shouldn't the problem be the "ancient hardware that doesn't have bash" itself?

A brand new macbook pro will not have bash4.

The machine may not be ancient but I would still argue that the problem there is the ~10 year old version of Bash that Apple has decided to ship rather than the programmers that use features added to the shell within the last 10 years.

(I should add that I don't know what version High Sierra ships with but Sierra seemed to ship with 3.2.5x-ish which was 9 years old at the time.)

Well put it this way:

You can assume everyone has a modern bash, and make it the end users problem if they don't, or you can write portable shell scripts and know it will work.

Honestly the things you can't do in posix shell compared to bash border on "use a fully featured language" anyway.

Thing is that Bash is something you can assume to be reasonably widely available[0] — like Perl or Python — but I wouldn't expect to have to avoid any features from the last 10 years of either of those two. Sure, a certain grace period is to be expected but I think 10 years is way past that.

[0]: I know POSIX is supposed to be even more widely available but depending on what you're targeting then it may not be the best option [source: https://en.wikipedia.org/wiki/POSIX#POSIX-oriented_operating...].

Afaik neither perl or python are gpl3-only licensed.

Thats the blocker on macOS.

How do you write a portable shell script? The programs invoked by your shell script need to behave the same everywhere. Even fundamental things like cp, rm, etc. don’t universally behave the same across the various Unix and Unix-like systems.

The joke is that your shell is actually more portable than your shell script :)

Most of the shell utilities described by posix have standard flags, and then gnu/bsd extra flags.

If you use the standard ones (and use the "posix mode" flags when available) you're mostly ok.

Also, a shell script can have logic to handle different tools available (either different flavours of the same tool or even different tools that do similar things).

If the basic syntax it uses (or the shebang) are bash specific then you need bash to run it.

And it's all 2 minutes to add it as your default shell (including installing brew itself).

  22:06  ~  $ bash --version
  GNU bash, version 4.4.12(1)-release (x86_64-apple-
  darwin16.3.0)

Much easier than constraining oneself about what to put in one's script (assuming one is indeed targeting Linux, OS X etc released in the last 10+ years and not some embedded etc platforms).

If your project says it requires something from brew thats a blocker for a number of people.

A mythical kind of project that depends on macOS having a recent bash?

If your project depends on a bash script and that script depends on bash4, it wont run out of the box on a brand new macOS machine.

A posix conptible shell script has no such limitation. Thats all im saying. Im not arguing the merits of which bash is better or what a project might need.

The article doesn't mention which are portable and which aren't.

It's a cultural thing. GNU is intended to replace Unix, so interoperability is (at best) not a priority. Same as Microsoft's “embrace, extend, extinguish”, which shows how important a good slogan is if you want your ambitions recognized.

A POSIX (or older Bourne-descended) shell can be distinguished from ‘bash --posix’ in a script with a fragment like “date&>F”, because Bash authors either didn't realize or didn't care that the sequence ‘&>’ already had meaning.

I wanted to argue that POSIX didn't define this behavior. But, reading the spec: I agree with you, Bash is non-compliant there.

According to POSIX (2016 edition)

    date&>F

should be equivalent to

    date &
    (exec >F)

where in Bash, it's equivalent to

    date >F 2>&1

Reply on news.ycombinator.com