7 ms·

This article is not specifically about Bash, but about the shell command language sh. The POSIX Shell is a standardized subset of Bash which has even better por

This article is not specifically about Bash, but about the shell command language sh. The POSIX Shell is a standardized subset of Bash which has even better portability. I would recommend learning and using sh unless you really need Bash. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... Your script will use sh if it starts with #!/bin/sh (instead of #!/bin/bash). I can also recommend ShellCheck which is a shell script analysis tool (implemented in Haskell) which can find errors and potential problems in your scripts. On a Debian system, installing ShellScheck is as simple as `sudo apt install shellcheck'.

spyremeown 3y ago
>I would recommend learning and using sh unless you really need Bash. I don't buy this argument. Ok, it's a standard, but sometimes it's a pain-in-the-hole standard. Bash augmentations lessen some of the pains, and it's just nicer. The only situation is if you're using busybox in a very limited system or you reeeeeally need your script to run on many difference unices, which let's be honest, is not that common nowadays.
- JdeBP 3y ago
  All of this was covered in great detail in the 2000s, when Debian and Ubuntu switched /bin/sh to the Debian Almquist shell, which was basically POSIX-only with some 3 things that Debian people simply couldn't live without, and encouraged system scripts to use it. If you weren't around then, go and read the discussions. They're mostly still available, and they cover some important stuff that straw man counterarguments regularly miss. The Debian people were concerned, for starters, with how much time the Bourne Again shell spent, at process initialization, setting up things for extensions and interactive features that were never employed in non-interactive "sh" mode; a significant cause for concern given how much of the system was executable shell scripts.
  - jmclnx 3y ago
    >with some 3 things that Debian people simply couldn't live without Curious, what are the 3 things ? But yes, people should always use sh (or ksh) for scripting as opposed to bash, why, it is far more portable to other systems.
    - JdeBP 3y ago
      Originally it was echo -n, local, and logical operators in test. There was just so much Debian stuff that assumed these. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294962 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294962 They've added 2 more since. * https://www.debian.org/doc/debian-policy/ch-files.html#scripts https://www.debian.org/doc/debian-policy/ch-files.html#scrip... Strictly speaking, there are other differences between the Debian Almquist shell and a truly SUS conformant sh. * https://unix.stackexchange.com/q/697007/5132 https://unix.stackexchange.com/q/697007/5132 But the aforementioned are what Debian people explicitly wanted and couldn't live without. Note that the StackExchange answer is a comparison of a 2022 dash to a 2017 standard, neither of which existed at the time. Debian Policy, the Debian Almquist shell, and the POSIX standard have all been revised since then.
- kaba0 3y ago
  > Bash augmentations lessen some of the pains, and it's just nicer Both sh and bash are terrible, ugly hacks. Anything that requires more than 3 lines of them (including the #! line) should be written in a proper scripting language. Though I do agree that cross-platformity to that level is rarely meaningful, and so things like python are just as likely available/can be made available.
  - ndsipa_pomu 3y ago
    Which version of python though?
    - kaba0 3y ago
      Add a flake.nix file and you get completely reproducible program versions if you really want. But I know that you meant it as a rhetoric, so my non-rhetorical answer would be that python3 is almost universally available on distros that are not minified deliberately (containers).
      - ndsipa_pomu 3y ago
        > python3 is almost universally available on distros that are not minified deliberately (containers) Writing control scripts for use inside containers is currently my biggest application of BASH scripts. What makes BASH (or other shells) handy is the lack of supporting files that are needed - just copy in the script and you're ready to go.
        time0ut 3y ago
        I was going to say something similar. I try to avoid adding anything to my final images. Each extra dependency is something else to update, more surface areas for attacks, another thing to justify, etc. Much rather just use the slimmest base and the tools already available.
    - paulddraper 3y ago
      3 Which version of Bash?
- blueflow 3y ago
  > is not that common nowadays Due to docker, minimalistic Linux'es have been more common, including trimmed-down versions of distros that would otherwise feature bash.
  - synergy20 3y ago
    bash is rarely the focus though, it really just costs 1MB in storage, which is nothing comparing to python,etc.
    - paulddraper 3y ago
      Nonetheless Bash is very frequently omitted in my experience.
    - 9dev 3y ago
      Well, usually I have to decide between „do I look up the magic incantation to install bash in this container and risk fucking up the layer cache“ or „do I modify this script to not use bash-isms and feel like I’m a Unix purist in the process“, and the answer is the latter usually
    - foobarian 3y ago
      Just 1MB? That's most of a double-density floppy disk!
- synergy20 3y ago
  I do small embedded systems with busybox, even that I can squeeze in bash when I need that, it's about 1MB in size and gives a lot more than busybox's sh. Another option is Lua which is also great.
- yyyk 3y ago
  If you wish require some users to install an interpreter, you might as well go for Korn or a real programming language. If you want to use something that's portable and installed everywhere, that's POSIX sh (or at most dash-like level). Bash is in the poor middle which isn't good enough for either side, unless you really know what's your target and don't care about elsewhere.
ndsipa_pomu 3y ago
I usually target BASHv3 in my scripts, but then I know the environment that will be using those scripts. My biggest issue with POSIX is the use of the backtick which is difficult to read and parse. ShellCheck is absolutely the most important thing to use when writing scripts. Each time that you get a warning that you don't recognise is a learning opportunity - just follow the link provided in the warning. Also, take the time to add the "# shellcheck disable=" comments so that scripts don't issue any warnings from shellcheck. I also recommend visiting https://mywiki.wooledge.org/BashFAQ https://mywiki.wooledge.org/BashFAQ for avoiding the many footguns, especially with filename parsing.
- rascul 3y ago
  > My biggest issue with POSIX is the use of the backtick which is difficult to read and parse. POSIX also has $(command) for command substitution. It can certainly be annoying when it's not used, though. I think shellcheck will recommend it over backticks.
  - ndsipa_pomu 3y ago
    Thanks, I didn't know that, but then I almost never target POSIX. My next complaint would be the use of '[' as a test rather than my preferred '[['. Edit: After looking for a problem with POSIX, I found this obscure issue that may well catch out people as under POSIX, IFS is a terminator rather than a separator: https://mywiki.wooledge.org/BashPitfalls#IFS.3D.2C_read_-ra_fields_.3C.3C.3C_.22.24csv_line.22 https://mywiki.wooledge.org/BashPitfalls#IFS.3D.2C_read_-ra_...
- augustk 3y ago
  > My biggest issue with POSIX is the use of the backtick which is difficult to read and parse. I always use $(...) or rather "$(...)" instead of backticks. Command substitution shall occur when the command is enclosed as follows: $(command) or (backquoted version): `command` https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
rascul 3y ago
I recommend learning bash if you know that bash is available for all your targets, since bash brings many niceties that sh doesn't have.
- justaj 3y ago
  Some may have different Bash versions installed though.
  - rascul 3y ago
    That's easy to check for. sh implementations can vary also.
    - justaj 3y ago
      Does the POSIX implementation vary for sh though? AFAIK some interpreters choose to add some extras (like `local`), but all of them at the very minimum must adhere to the POSIX spec from what I've understood.
      - rascul 3y ago
        There are a couple examples in this stack overflow answer: https://stackoverflow.com/questions/11376975/is-there-a-minimally-posix-2-compliant-shell/16376043#16376043 https://stackoverflow.com/questions/11376975/is-there-a-mini...
dspillett 3y ago
> The POSIX Shell is a standardized subset of Bash which has even better portability. It would be much more correct to say that bash's features are a superset of the shell features standardised by the POSIX standard, as is the case for several other shells (each adding their own parts on top of the standard) too.
VWWHFSfQ 3y ago
> I would recommend learning and using sh unless you really need Bash. Nah I like using bash features and all the systems that I care about have /bin/bash so it doesn't matter.
latexr 3y ago
macOS and plenty of popular Linux distributions symlink /bin/sh to /bin/bash. Some link it to /bin/dash. There may be different ones. Meaning /bin/sh is not more portable because you can’t be sure which shell will be used.
- VWWHFSfQ 3y ago
  Not only is it not more portable, POSIX doesn't even require that it exists at all. Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in. I don't know how this trend started but now it's been cargo-culted to death. Same with the /usr/bin/env thing in shebangs.
  - shawabawa3 3y ago
    One use-case for /bin/sh over /bin/bash these days is that the alpine docker image (base image for a lot of docker images) has /bin/sh but not /bin/bash
- jsyolo 3y ago
  Bash is POSiX compatible.
- augustk 3y ago
  ShellCheck can check for POSIX compliance with the option `--shell sh', e.g. shellcheck --shell sh myscript.sh
- TristanBall 3y ago
  "If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well"
everybodyknows 3y ago
> This article is not specifically about Bash, but about the shell command language sh. Exactly. The title is just plain wrong. Furthermore, TFA does not argue a "case", it simply tries to specify the language.
myhf 3y ago
> not specifically about Bash, but about the shell command language sh or as I've taken to calling it, Ba + sh

spyremeown 3y ago

>I would recommend learning and using sh unless you really need Bash. I don't buy this argument. Ok, it's a standard, but sometimes it's a pain-in-the-hole standard. Bash augmentations lessen some of the pains, and it's just nicer. The only situation is if you're using busybox in a very limited system or you reeeeeally need your script to run on many difference unices, which let's be honest, is not that common nowadays.

JdeBP 3y ago
All of this was covered in great detail in the 2000s, when Debian and Ubuntu switched /bin/sh to the Debian Almquist shell, which was basically POSIX-only with some 3 things that Debian people simply couldn't live without, and encouraged system scripts to use it. If you weren't around then, go and read the discussions. They're mostly still available, and they cover some important stuff that straw man counterarguments regularly miss. The Debian people were concerned, for starters, with how much time the Bourne Again shell spent, at process initialization, setting up things for extensions and interactive features that were never employed in non-interactive "sh" mode; a significant cause for concern given how much of the system was executable shell scripts.
- jmclnx 3y ago
  >with some 3 things that Debian people simply couldn't live without Curious, what are the 3 things ? But yes, people should always use sh (or ksh) for scripting as opposed to bash, why, it is far more portable to other systems.
  - JdeBP 3y ago
    Originally it was echo -n, local, and logical operators in test. There was just so much Debian stuff that assumed these. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294962 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294962 They've added 2 more since. * https://www.debian.org/doc/debian-policy/ch-files.html#scripts https://www.debian.org/doc/debian-policy/ch-files.html#scrip... Strictly speaking, there are other differences between the Debian Almquist shell and a truly SUS conformant sh. * https://unix.stackexchange.com/q/697007/5132 https://unix.stackexchange.com/q/697007/5132 But the aforementioned are what Debian people explicitly wanted and couldn't live without. Note that the StackExchange answer is a comparison of a 2022 dash to a 2017 standard, neither of which existed at the time. Debian Policy, the Debian Almquist shell, and the POSIX standard have all been revised since then.
kaba0 3y ago
> Bash augmentations lessen some of the pains, and it's just nicer Both sh and bash are terrible, ugly hacks. Anything that requires more than 3 lines of them (including the #! line) should be written in a proper scripting language. Though I do agree that cross-platformity to that level is rarely meaningful, and so things like python are just as likely available/can be made available.
- ndsipa_pomu 3y ago
  Which version of python though?
  - kaba0 3y ago
    Add a flake.nix file and you get completely reproducible program versions if you really want. But I know that you meant it as a rhetoric, so my non-rhetorical answer would be that python3 is almost universally available on distros that are not minified deliberately (containers).
    - ndsipa_pomu 3y ago
      > python3 is almost universally available on distros that are not minified deliberately (containers) Writing control scripts for use inside containers is currently my biggest application of BASH scripts. What makes BASH (or other shells) handy is the lack of supporting files that are needed - just copy in the script and you're ready to go.
      - time0ut 3y ago
        I was going to say something similar. I try to avoid adding anything to my final images. Each extra dependency is something else to update, more surface areas for attacks, another thing to justify, etc. Much rather just use the slimmest base and the tools already available.
  - paulddraper 3y ago
    3 Which version of Bash?
blueflow 3y ago
> is not that common nowadays Due to docker, minimalistic Linux'es have been more common, including trimmed-down versions of distros that would otherwise feature bash.
- synergy20 3y ago
  bash is rarely the focus though, it really just costs 1MB in storage, which is nothing comparing to python,etc.
  - paulddraper 3y ago
    Nonetheless Bash is very frequently omitted in my experience.
  - 9dev 3y ago
    Well, usually I have to decide between „do I look up the magic incantation to install bash in this container and risk fucking up the layer cache“ or „do I modify this script to not use bash-isms and feel like I’m a Unix purist in the process“, and the answer is the latter usually
  - foobarian 3y ago
    Just 1MB? That's most of a double-density floppy disk!
synergy20 3y ago
I do small embedded systems with busybox, even that I can squeeze in bash when I need that, it's about 1MB in size and gives a lot more than busybox's sh. Another option is Lua which is also great.
yyyk 3y ago
If you wish require some users to install an interpreter, you might as well go for Korn or a real programming language. If you want to use something that's portable and installed everywhere, that's POSIX sh (or at most dash-like level). Bash is in the poor middle which isn't good enough for either side, unless you really know what's your target and don't care about elsewhere.

ndsipa_pomu 3y ago

I usually target BASHv3 in my scripts, but then I know the environment that will be using those scripts. My biggest issue with POSIX is the use of the backtick which is difficult to read and parse. ShellCheck is absolutely the most important thing to use when writing scripts. Each time that you get a warning that you don't recognise is a learning opportunity - just follow the link provided in the warning. Also, take the time to add the "# shellcheck disable=" comments so that scripts don't issue any warnings from shellcheck. I also recommend visiting https://mywiki.wooledge.org/BashFAQ https://mywiki.wooledge.org/BashFAQ for avoiding the many footguns, especially with filename parsing.

rascul 3y ago
> My biggest issue with POSIX is the use of the backtick which is difficult to read and parse. POSIX also has $(command) for command substitution. It can certainly be annoying when it's not used, though. I think shellcheck will recommend it over backticks.
- ndsipa_pomu 3y ago
  Thanks, I didn't know that, but then I almost never target POSIX. My next complaint would be the use of '[' as a test rather than my preferred '[['. Edit: After looking for a problem with POSIX, I found this obscure issue that may well catch out people as under POSIX, IFS is a terminator rather than a separator: https://mywiki.wooledge.org/BashPitfalls#IFS.3D.2C_read_-ra_fields_.3C.3C.3C_.22.24csv_line.22 https://mywiki.wooledge.org/BashPitfalls#IFS.3D.2C_read_-ra_...
augustk 3y ago
> My biggest issue with POSIX is the use of the backtick which is difficult to read and parse. I always use $(...) or rather "$(...)" instead of backticks. Command substitution shall occur when the command is enclosed as follows: $(command) or (backquoted version): `command` https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

rascul 3y ago

I recommend learning bash if you know that bash is available for all your targets, since bash brings many niceties that sh doesn't have.

justaj 3y ago
Some may have different Bash versions installed though.
- rascul 3y ago
  That's easy to check for. sh implementations can vary also.
  - justaj 3y ago
    Does the POSIX implementation vary for sh though? AFAIK some interpreters choose to add some extras (like `local`), but all of them at the very minimum must adhere to the POSIX spec from what I've understood.
    - rascul 3y ago
      There are a couple examples in this stack overflow answer: https://stackoverflow.com/questions/11376975/is-there-a-minimally-posix-2-compliant-shell/16376043#16376043 https://stackoverflow.com/questions/11376975/is-there-a-mini...

dspillett 3y ago

> The POSIX Shell is a standardized subset of Bash which has even better portability. It would be much more correct to say that bash's features are a superset of the shell features standardised by the POSIX standard, as is the case for several other shells (each adding their own parts on top of the standard) too.

VWWHFSfQ 3y ago

> I would recommend learning and using sh unless you really need Bash. Nah I like using bash features and all the systems that I care about have /bin/bash so it doesn't matter.

latexr 3y ago

macOS and plenty of popular Linux distributions symlink /bin/sh to /bin/bash. Some link it to /bin/dash. There may be different ones. Meaning /bin/sh is not more portable because you can’t be sure which shell will be used.

VWWHFSfQ 3y ago
Not only is it not more portable, POSIX doesn't even require that it exists at all. Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in. I don't know how this trend started but now it's been cargo-culted to death. Same with the /usr/bin/env thing in shebangs.
- shawabawa3 3y ago
  One use-case for /bin/sh over /bin/bash these days is that the alpine docker image (base image for a lot of docker images) has /bin/sh but not /bin/bash
jsyolo 3y ago
Bash is POSiX compatible.
augustk 3y ago
ShellCheck can check for POSIX compliance with the option `--shell sh', e.g. shellcheck --shell sh myscript.sh
TristanBall 3y ago
"If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well"

everybodyknows 3y ago

> This article is not specifically about Bash, but about the shell command language sh. Exactly. The title is just plain wrong. Furthermore, TFA does not argue a "case", it simply tries to specify the language.

myhf 3y ago

> not specifically about Bash, but about the shell command language sh or as I've taken to calling it, Ba + sh