6 ms·

For portability reasons I prefer to write POSIX shell scripts instead of Bash scripts: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.htm

For portability reasons I prefer to write POSIX shell scripts instead of Bash scripts: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

zimbatm 6y ago
I used to think that way, but POSIX is not that well specified and there are tons of little behavior changes that makes the task difficult past 10 lines of code. Writing portable shell scripts is like writing portable JavaScript in the IE days. https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible is a good example if you look at the issue tracker. Once you accept Bash as a standard things become much easier. Basically Bash arrays, the `@Q` notation and ShellCheck combined solve all of the escaping issues that plague shell scripts.
- michaelcampbell 6y ago
  I can't think of a system that would be using anything I write that wouldn't have bash, honestly. Not in... 25 years or so. "portability" I guess is a goal, to a degree, for me too since I write in bash instead of zsh which I use interactively, but /bin/sh scripts for "portability" is just a fetish, IMO.
  - apple4ever 6y ago
    Ya bash is at least installed on everything modern now. Maybe that changes, but if you right for bash that's portable enough - you need to balance the work required with the risks of not doing it.
- joombaga 6y ago
  What is @Q notation?
  - cb321 6y ago
    I belive zimbatm refers to the bash-specific ${var@Q} to expand to a form suitable as re-input into the shell. There are a few other bash-specific syntaxes like that (under "parameter transformation" in the manual page).
  - zimbatm 6y ago
    What cb321 said. Sometimes programs take a single argument that contains the whole command. @Q allows to safely escape the list of arguments. This is a synthetic example: args=("my" "arg" "with space") bash -c "rm ${args[*]@Q}" This makes sure that the script will `rm` "my" "arg" and "with space", and not "with" and "space" :)
  - graton 6y ago
    I found this info: https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html https://www.gnu.org/software/bash/manual/html_node/Shell-Par... ${parameter@operator} The expansion is either a transformation of the value of parameter or information about parameter itself, depending on the value of operator. Each operator is a single letter: Q The expansion is a string that is the value of parameter quoted in a format that can be reused as input.
- lukeschlather 6y ago
  Bash and shellcheck mitigate the issues but Powershell (and some newer shells like Elvish and Oil) actually solve the issues by introducing proper objects and breaking the defaults bash expects. Bash suffers from a similar problem to Perl and other 20+ year old "get it done" languages that they need a strict-mode bolted on, and a bolted-on strict mode is strictly inferior to just having the language behave sensibly to begin with.
  - zimbatm 6y ago
    100% agreed, if you can choose your own language, there are certainly better options than Bash. It depends if you can do that or not. In some contexts, Python is also a pretty good option as it is available in a lot of places as well.
- turminal 6y ago
  > Once you accept Bash as a standard things become much easier. They also become nonstandard.
  - zimbatm 6y ago
    That's how I used to think as well. But you can also see Bash of being a standard on its own :) Obviously it all depends on the context.
patrec 6y ago
Unless you have an encyclopedic memory and copious leisure time, you'd probably be much better off writing perl scripts instead if you care about portability. There is an enormous amount of sometimes subtle divergence between behaviors of core tools you need for shell scripting (sed, tr, mktemp, readlink all behave very differently between different versions of unix,for example) and even if you manage to memorize exactly what's in posix (and accept the fairly severe limitiations in expressiveness this entails), few things are actually 100% posix conforming.
- arendtio 6y ago
  AFAIK, mktemp is not part of POSIX. I use the POSIX documentation as my primary source of documentation when writing scripts. Most of the time, I have seen that the differences between the implementations are in the additions but not in the core functionalities that are described by POSIX. A nice entry to the POSIX documentation is being provided by this website: https://shellhaters.org https://shellhaters.org
arendtio 6y ago
While I appreciate the existence of POSIX as a standard, I wonder how we could come to a place where it would be actually good. Don't get me wrong, there are many positive things about POSIX shells, but in my opinion, the language itself is broken (how many errors are caused by whitespace in the wrong place?) and error handling in particular is just horrible and unreliable. There are many better designed languages out there, but to this date, none is as omnipresent as the POSIX shell language.

zimbatm 6y ago

I used to think that way, but POSIX is not that well specified and there are tons of little behavior changes that makes the task difficult past 10 lines of code. Writing portable shell scripts is like writing portable JavaScript in the IE days. https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible is a good example if you look at the issue tracker. Once you accept Bash as a standard things become much easier. Basically Bash arrays, the `@Q` notation and ShellCheck combined solve all of the escaping issues that plague shell scripts.

michaelcampbell 6y ago
I can't think of a system that would be using anything I write that wouldn't have bash, honestly. Not in... 25 years or so. "portability" I guess is a goal, to a degree, for me too since I write in bash instead of zsh which I use interactively, but /bin/sh scripts for "portability" is just a fetish, IMO.
- apple4ever 6y ago
  Ya bash is at least installed on everything modern now. Maybe that changes, but if you right for bash that's portable enough - you need to balance the work required with the risks of not doing it.
joombaga 6y ago
What is @Q notation?
- cb321 6y ago
  I belive zimbatm refers to the bash-specific ${var@Q} to expand to a form suitable as re-input into the shell. There are a few other bash-specific syntaxes like that (under "parameter transformation" in the manual page).
- zimbatm 6y ago
  What cb321 said. Sometimes programs take a single argument that contains the whole command. @Q allows to safely escape the list of arguments. This is a synthetic example: args=("my" "arg" "with space") bash -c "rm ${args[*]@Q}" This makes sure that the script will `rm` "my" "arg" and "with space", and not "with" and "space" :)
- graton 6y ago
  I found this info: https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html https://www.gnu.org/software/bash/manual/html_node/Shell-Par... ${parameter@operator} The expansion is either a transformation of the value of parameter or information about parameter itself, depending on the value of operator. Each operator is a single letter: Q The expansion is a string that is the value of parameter quoted in a format that can be reused as input.
lukeschlather 6y ago
Bash and shellcheck mitigate the issues but Powershell (and some newer shells like Elvish and Oil) actually solve the issues by introducing proper objects and breaking the defaults bash expects. Bash suffers from a similar problem to Perl and other 20+ year old "get it done" languages that they need a strict-mode bolted on, and a bolted-on strict mode is strictly inferior to just having the language behave sensibly to begin with.
- zimbatm 6y ago
  100% agreed, if you can choose your own language, there are certainly better options than Bash. It depends if you can do that or not. In some contexts, Python is also a pretty good option as it is available in a lot of places as well.
turminal 6y ago
> Once you accept Bash as a standard things become much easier. They also become nonstandard.
- zimbatm 6y ago
  That's how I used to think as well. But you can also see Bash of being a standard on its own :) Obviously it all depends on the context.

patrec 6y ago

Unless you have an encyclopedic memory and copious leisure time, you'd probably be much better off writing perl scripts instead if you care about portability. There is an enormous amount of sometimes subtle divergence between behaviors of core tools you need for shell scripting (sed, tr, mktemp, readlink all behave very differently between different versions of unix,for example) and even if you manage to memorize exactly what's in posix (and accept the fairly severe limitiations in expressiveness this entails), few things are actually 100% posix conforming.

arendtio 6y ago
AFAIK, mktemp is not part of POSIX. I use the POSIX documentation as my primary source of documentation when writing scripts. Most of the time, I have seen that the differences between the implementations are in the additions but not in the core functionalities that are described by POSIX. A nice entry to the POSIX documentation is being provided by this website: https://shellhaters.org https://shellhaters.org

arendtio 6y ago

While I appreciate the existence of POSIX as a standard, I wonder how we could come to a place where it would be actually good. Don't get me wrong, there are many positive things about POSIX shells, but in my opinion, the language itself is broken (how many errors are caused by whitespace in the wrong place?) and error handling in particular is just horrible and unreliable. There are many better designed languages out there, but to this date, none is as omnipresent as the POSIX shell language.