4 ms·

+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 t

+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.

rocqua 9y ago
The article doesn't mention which are portable and which aren't.
- kps 9y ago
  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.
  - LukeShu 9y ago
    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
coldtea 9y ago
>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?
- stephenr 9y ago
  A brand new macbook pro will not have bash4.
  - lillesvin 9y ago
    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.)
    - stephenr 9y ago
      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.
      - sigjuice 9y ago
        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 :)
        stephenr 9y ago
        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.

rocqua 9y ago

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

kps 9y ago
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.
- LukeShu 9y ago
  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

coldtea 9y ago

>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?

stephenr 9y ago
A brand new macbook pro will not have bash4.
- lillesvin 9y ago
  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.)
  - stephenr 9y ago
    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.
    - sigjuice 9y ago
      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 :)
      - stephenr 9y ago
        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.