7 ms·

The same amazing guy also published the Pure sh Bible: https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible

1vuio0pswjnm7 3y ago
That's not dash, it's bash in POSIX compatibility mode. dash does not implement all the POSIX stuff in this "bible". Imagine using this "bible" to write a "pure sh" script thinking "this will be highly portable", only to have it fail because the Linux scripting shell is not bash in POSIX compatibility mode, it's dash. It would fail on NetBSD, too, whose scripting shell is the version of ash from which dash is derived.
- prmoustache 3y ago
  Do people actually symlink /bin/dash to /bin/sh? That would be extremely stupid.
  - balou23 3y ago
    Debian and Ubuntu do it by default
  - throw0101b 3y ago
    > That would be extremely stupid. Why?
    - prmoustache 3y ago
      Because if you are not 100% compatible with bourne shell you shouldn't automatically execute script made for bourne shell. I have no problem with people using #!/bin/dash shebang for their scripts and using dash as their default shell but it shouldn't pass itself as something else. It is fine with bash because it is bourne shell compatible.
      - throw0101b 3y ago
        > Because if you are not 100% compatible with bourne shell you shouldn't automatically execute script made for bourne shell. The same can be said about bash. > It is fine with bash because it is bourne shell compatible. I was running an HPC cluster when we upgraded Debian during the bash->dash change, and there were all sorts of problems: IIRC most folks simply changed their scripts from /bin/sh to /bin/bash.
- happymellon 3y ago
  > dash does not implement all the POSIX stuff Then it doesn't sound fit for scripting.
- Crestwave 3y ago
  Do you have any specific examples to cite? The snippets are meant to be run in POSIX-compliant shells like dash/yash/ash/etc, not just Bash in compatibility mode. In fact, there used to be a section which listed workarounds[1] for bugs in dash, but they have since been fixed[2]. If you are still using an old version of dash, you may need to use them. [1] https://github.com/dylanaraps/pure-sh-bible/commit/70f410ebb2b0d54cab1b1d4db3804c654db9619a https://github.com/dylanaraps/pure-sh-bible/commit/70f410ebb... [2] https://github.com/dylanaraps/pure-sh-bible/issues/13 https://github.com/dylanaraps/pure-sh-bible/issues/13
  - 1vuio0pswjnm7 3y ago
    https://news.ycombinator.com/item?id=35768615 https://news.ycombinator.com/item?id=35768615 Perhaps dash now has these features but does NetBSD sh or FreeBSD sh have them. What's the point of "pure sh" if it's restricted to specific versions of shells. Opinions may differ but I'd rather learn the "lowest common denominator". I use the same scripts on both Linux and BSD so I need portability. I do not use bash for scripting. It's larger and slower. One source I consult is https://www.in-ulm.de/~mascheck/bourne/ https://www.in-ulm.de/~mascheck/bourne/ It is sometimes submitted to HN, but not IMO enough https://news.ycombinator.com/from?site=in-ulm.de https://news.ycombinator.com/from?site=in-ulm.de I'm using the latest version of dash. I just tested it and it does have these ternary operators. However, I'm not going to use them in scripts unless I know they'll work on older dash versions, OpenWRT sh, Android sh, NetBSD sh, FreeBSD sh, etc. The process of updating these shells is generally very slow. It can take years. "Pure sh" implies there is some advantage over "bashisms". I thought maybe it was portability but perhaps it is something else.
    - ftaghn 3y ago
      > and slower. I like to write posix sh scripts for the sake of portability and, funnily enough, future proofing as I don't like having to maintain stuff against changes that break compatibility, which is something bash does (archlinux is still on an older bash even though debian stable has the latest, because bash 5.2 broke some of archlinux's own scripts. This is why you should not write bash scripts.), but bash being slow isn't one of the good reasons. If your scripts do that much work that your shell's speed matters, you should reconsider writing shell scripts and start thinking about using something like perl, python or ruby. I'd suggest perl, if only because unlike the latter, perl doesn't constantly pull the rug under you and make you do busy work to make sure your scripts work on the latest runtimes.
- throw0101b 3y ago
  > That's not dash, it's bash in POSIX compatibility mode. I was under the impression that bash's POSIX mode was 'leaky': that a lot of non-POSIX stuff/extensions are available even though it's called as /bin/sh. I know this caused a lot of our users issues when we upgraded Debian/Ubuntu during its switchover to dash. We told folks you could either rewrite those parts of the code or call /bin/bash. * https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh * https://lwn.net/Articles/343924/ https://lwn.net/Articles/343924/
  - chasil 3y ago
    One major reason that Debian chose dash is plainly written on the bash manual page: $ man bash | sed -n '/BUGS/,/^$/p' BUGS It's too big and too slow. Another major reason is adherence to the POSIX standard; bash was written a decade prior to standardization, and has interesting issues because of this. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
    - throw0101b 3y ago
      > bash was written a decade prior to standardization, and has interesting issues because of this. bash can do whatever it wants to do if it's called as "bash". But it should only do specific things when called as "sh". This is true of any shell: > When interpreted with dash instead of bash, the same script will fail. This is because dash is much stricter than bash in following the sh standard. Since dash is designed as a minimal implementation of the sh standard, it has to be stricter. The double brackets [[ … ]] are a ‘bashism,’ or a feature only available in bash and other, later shells such as ksh and zsh. > Even though zsh also interprets most of these bashisms, zsh in sh compatibility mode is also stricter than bash and will error. * https://scriptingosx.com/2020/06/about-bash-zsh-sh-and-dash-in-macos-catalina-and-beyond/ https://scriptingosx.com/2020/06/about-bash-zsh-sh-and-dash-... * https://zsh.sourceforge.io/Doc/Release/Invocation.html#Compatibility https://zsh.sourceforge.io/Doc/Release/Invocation.html#Compa... POSIX.2: Shell and Utilities (IEEE Std 1003.2-1992) is a few decades old now: regardless of when bash development started, I would think that by the 2010s it would have managed to better compartmentalize compatibility and extensions.

1vuio0pswjnm7 3y ago

That's not dash, it's bash in POSIX compatibility mode. dash does not implement all the POSIX stuff in this "bible". Imagine using this "bible" to write a "pure sh" script thinking "this will be highly portable", only to have it fail because the Linux scripting shell is not bash in POSIX compatibility mode, it's dash. It would fail on NetBSD, too, whose scripting shell is the version of ash from which dash is derived.

prmoustache 3y ago
Do people actually symlink /bin/dash to /bin/sh? That would be extremely stupid.
- balou23 3y ago
  Debian and Ubuntu do it by default
- throw0101b 3y ago
  > That would be extremely stupid. Why?
  - prmoustache 3y ago
    Because if you are not 100% compatible with bourne shell you shouldn't automatically execute script made for bourne shell. I have no problem with people using #!/bin/dash shebang for their scripts and using dash as their default shell but it shouldn't pass itself as something else. It is fine with bash because it is bourne shell compatible.
    - throw0101b 3y ago
      > Because if you are not 100% compatible with bourne shell you shouldn't automatically execute script made for bourne shell. The same can be said about bash. > It is fine with bash because it is bourne shell compatible. I was running an HPC cluster when we upgraded Debian during the bash->dash change, and there were all sorts of problems: IIRC most folks simply changed their scripts from /bin/sh to /bin/bash.
happymellon 3y ago
> dash does not implement all the POSIX stuff Then it doesn't sound fit for scripting.
Crestwave 3y ago
Do you have any specific examples to cite? The snippets are meant to be run in POSIX-compliant shells like dash/yash/ash/etc, not just Bash in compatibility mode. In fact, there used to be a section which listed workarounds[1] for bugs in dash, but they have since been fixed[2]. If you are still using an old version of dash, you may need to use them. [1] https://github.com/dylanaraps/pure-sh-bible/commit/70f410ebb2b0d54cab1b1d4db3804c654db9619a https://github.com/dylanaraps/pure-sh-bible/commit/70f410ebb... [2] https://github.com/dylanaraps/pure-sh-bible/issues/13 https://github.com/dylanaraps/pure-sh-bible/issues/13
- 1vuio0pswjnm7 3y ago
  https://news.ycombinator.com/item?id=35768615 https://news.ycombinator.com/item?id=35768615 Perhaps dash now has these features but does NetBSD sh or FreeBSD sh have them. What's the point of "pure sh" if it's restricted to specific versions of shells. Opinions may differ but I'd rather learn the "lowest common denominator". I use the same scripts on both Linux and BSD so I need portability. I do not use bash for scripting. It's larger and slower. One source I consult is https://www.in-ulm.de/~mascheck/bourne/ https://www.in-ulm.de/~mascheck/bourne/ It is sometimes submitted to HN, but not IMO enough https://news.ycombinator.com/from?site=in-ulm.de https://news.ycombinator.com/from?site=in-ulm.de I'm using the latest version of dash. I just tested it and it does have these ternary operators. However, I'm not going to use them in scripts unless I know they'll work on older dash versions, OpenWRT sh, Android sh, NetBSD sh, FreeBSD sh, etc. The process of updating these shells is generally very slow. It can take years. "Pure sh" implies there is some advantage over "bashisms". I thought maybe it was portability but perhaps it is something else.
  - ftaghn 3y ago
    > and slower. I like to write posix sh scripts for the sake of portability and, funnily enough, future proofing as I don't like having to maintain stuff against changes that break compatibility, which is something bash does (archlinux is still on an older bash even though debian stable has the latest, because bash 5.2 broke some of archlinux's own scripts. This is why you should not write bash scripts.), but bash being slow isn't one of the good reasons. If your scripts do that much work that your shell's speed matters, you should reconsider writing shell scripts and start thinking about using something like perl, python or ruby. I'd suggest perl, if only because unlike the latter, perl doesn't constantly pull the rug under you and make you do busy work to make sure your scripts work on the latest runtimes.
throw0101b 3y ago
> That's not dash, it's bash in POSIX compatibility mode. I was under the impression that bash's POSIX mode was 'leaky': that a lot of non-POSIX stuff/extensions are available even though it's called as /bin/sh. I know this caused a lot of our users issues when we upgraded Debian/Ubuntu during its switchover to dash. We told folks you could either rewrite those parts of the code or call /bin/bash. * https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh * https://lwn.net/Articles/343924/ https://lwn.net/Articles/343924/
- chasil 3y ago
  One major reason that Debian chose dash is plainly written on the bash manual page: $ man bash | sed -n '/BUGS/,/^$/p' BUGS It's too big and too slow. Another major reason is adherence to the POSIX standard; bash was written a decade prior to standardization, and has interesting issues because of this. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
  - throw0101b 3y ago
    > bash was written a decade prior to standardization, and has interesting issues because of this. bash can do whatever it wants to do if it's called as "bash". But it should only do specific things when called as "sh". This is true of any shell: > When interpreted with dash instead of bash, the same script will fail. This is because dash is much stricter than bash in following the sh standard. Since dash is designed as a minimal implementation of the sh standard, it has to be stricter. The double brackets [[ … ]] are a ‘bashism,’ or a feature only available in bash and other, later shells such as ksh and zsh. > Even though zsh also interprets most of these bashisms, zsh in sh compatibility mode is also stricter than bash and will error. * https://scriptingosx.com/2020/06/about-bash-zsh-sh-and-dash-in-macos-catalina-and-beyond/ https://scriptingosx.com/2020/06/about-bash-zsh-sh-and-dash-... * https://zsh.sourceforge.io/Doc/Release/Invocation.html#Compatibility https://zsh.sourceforge.io/Doc/Release/Invocation.html#Compa... POSIX.2: Shell and Utilities (IEEE Std 1003.2-1992) is a few decades old now: regardless of when bash development started, I would think that by the 2010s it would have managed to better compartmentalize compatibility and extensions.