3 ms·

Obsessing over POSIX purity is a pointless endeavor. It should stay in its corner, but is largely a waste of time outside of corner cases. Do not mix the two an

Obsessing over POSIX purity is a pointless endeavor. It should stay in its corner, but is largely a waste of time outside of corner cases. Do not mix the two and understand the differences, but remaining locked inside a cage you make for yourself is a pointless show. The real world has bash everywhere that matters. PS: Be good, or I'll replace you with a very small zsh script. ;) Interestingly, it possible to dynamically add additional native commands to both zsh and bash in other languages. LuaBash and bash-loadables are examples.

chasil 2y ago
Advanced shell features will not run with dash, which is (almost) strict POSIX. They also fail with busybox. There are many subtle differences between BASH and Korn, so much will not run without rewrite on Android's mksh. Because you have not needed portable scripts yourself does not imply that the need is not vast.
- 3np 2y ago
  Classic IAGNI/YAGNI conflation.
- Etheryte 2y ago
  In many cases, the fact that it's far from trivial to figure out whether your script is portable or not, makes them not portable for practical intents and purposes. I would say that for most people and most use cases, shell scripts are write once and hope you never have to edit them again, and even knowing one way of comparing values may be problematic while another might not be is beyond the given pay grade.
  - dredmorbius 2y ago
    You can of course test portability by testing, or simply writing, your script against a POSIX-only shell interpretation. It's a lot easier to change a shebang (#!/bin/ash -> #!/bin/sh) than to rewrite the full script during a firefight. One might even suggest "/bin/bash considered harmful".
    - Joker_vD 2y ago
      One also may suggest "/bin/sh considered harmful". Does the rest of the world have to suffer just because Solaris can't be arsed to upgrade its tooling (much of it is very tentatively POSIX-compliant anyhow) so they block any new additions to the /bin/sh features in the POSIX?
      - chasil 2y ago
        The dash shell compiles to 80k on an i386, which is viable for embedded applications. The POSIX shell was standardized in view of the original Korn shell, which could compile to 64k on Xenix 286. The functionality was reduced in an effort to increase code maintainability. Edit: "A lot of effort was made to keep ksh88 small. In fact the size you report on Solaris is without stripping the symbol table. The size that I am getting for ksh88i on Solaris is 160K and the size on NetBSD on intel is 135K. "ksh88 was able to compile on machines that only allowed 64K text. There were many compromises to this approach. I gave up on size minimization with ksh93." https://m.slashdot.org/story/16351 https://m.slashdot.org/story/16351
      - dredmorbius 2y ago
        <https://news.ycombinator.com/item?id=41682985 https://news.ycombinator.com/item?id=41682985> It's hardly just Solaris.
      - deleted 2y ago
        [deleted]
  - pastage 2y ago
    This can be said of most programming, in Java, C++, golang, Pascal and Ruby I have been on projects that could not compile. The dependencies are so out dated a complete rewrite is easier. I do not find bash worse or better. You just do alot more with less lines in it.
  - chasil 2y ago
    If you use arrays, you cannot use dash.
- cmsj 2y ago
  The correct solution here is to pick one of the following options: 1) Write a bash script and put /bin/bash in your shebang 2) Write a POSIX shell script and integrate checkbashisms into your editor. Neither is more correct than the other.
  - chasil 2y ago
    3) #!/bin/dash
    - flir 2y ago
      #!/usr/bin/env dash I mean, if we're targeting portability...
  - dredmorbius 2y ago
    I believe many Linuxes still symlink /bin/sh -> /bin/bash, so the shebang itself won't save you. Debian's assignment of /bin/dash as the default /bin/sh is relatively recent (at least for those who've been running Debian since the 1990s). I virtually exclusively write Bash scripts for my own use. I've been bit by bashisms however, and at the very least don't casually dismiss the concerns which are voiced against doing this. I'm also daily using systems which don't have a full Bash, and which really don't have the resources to run it (mostly storage, though other factors may be involved).
  - yjftsjthsd-h 2y ago
    > Write a POSIX shell script and integrate checkbashisms into your editor. Suggestion: Use shellcheck. It will complain about bashisms if your script says #!/bin/sh and will also catch loads of other problems.
dredmorbius 2y ago
I've got sympathies with both sides of this argument. Bashisms are powerful, flexible, and occasionally performant. They're also non-portable, and you're apt to discover this whilst in an emergency situation with limited resources, most of all time. Having to edit shell scripts into POSIX conformance on a smartphone SSH session is No Bueno. There are an awful lot of systems which have either no, or old, Bash. Most prevalent of the latter is MacOS / OSX, which is now nagging me on each shell initialisation that the current supported standard is not bash but zsh. Scripts linked to /bin/bash will of course run, but the last update was version 3.2.57(1) if my system reports correctly. The most recent GNU Bash release is 5.3 according to <https://ftp.gnu.org/gnu/bash/ https://ftp.gnu.org/gnu/bash/>. And that's hardly the only old Bash floating around. On many systems, including many routers, DSL/cable modems, and other embedded devices, shell is some alternate variant (dash is /bin/sh on Debian, ash on RHEL's initrd IIRC, which last I fought with it was a script-only interpreter, not capable of running interactive commands, fucking annoying as hell). And there are still legacy Unix systems running Bourne, ksh, or other shells. Not to mention the phenomenal number of systems for which busybox provides much if not all of the userland environment, including /bin/sh. And is not bashism-capable. Ignoring POSIX works fantastically until it doesn't. Caveat scriptor.
- chasil 2y ago
  If you want the most powerful shell, ksh93 has the most features without doubt. Since David Korn retired, it has been adrift with few updates. The dash shell can be compiled with libedit to implement "set -o vi" (which is also POSIX), and is pleasant to use this way.
- imtringued 2y ago
  I don't know why someone would subject themselves to bash if the common argument in favour of it is a lie. People say that bash is already installed on the system. Then people like you point out that it isn't.
  - dredmorbius 2y ago
    Bash is installed on my own primary system(s). And generally a quite recent version. When I'm coding my own utility scripts (or more likely: writing one-liners which may get reused through shell history, possibly eventually being memorialised as scripts), I'll make heavy use of bashisms for the reasons I've noted elsewhere: powerful, convenient, often performant. But if I'm inflicting those or other scripts on other systems I'm highly cognisant that not all systems have either a modern bash, or bash at all, and will either write POSIX-conformant scripts there, or remove bashisms from my own scripts. That is, availing myself to benefits whilst recognising limits to my approach. A key benefit of scripting in the shell language used most frequently is that one is highly familiar with it. Scripting-only languages tend to be less familiar. They're also less available (sed and awk being the principle exceptions, which are also mandated under POSIX, and for which GNU variants also have idiosyncrasies (I run into this on MacOS all the time, and tend to make use of GNU sed/awk there). Perl, Ruby, Python, Lua, node.js, Tcl, etc., have more capabilities, but are also unavailable on a large number of systems. (Often old or small systems. to be sure, but numerous all the same.)

chasil 2y ago

Advanced shell features will not run with dash, which is (almost) strict POSIX. They also fail with busybox. There are many subtle differences between BASH and Korn, so much will not run without rewrite on Android's mksh. Because you have not needed portable scripts yourself does not imply that the need is not vast.

3np 2y ago
Classic IAGNI/YAGNI conflation.
Etheryte 2y ago
In many cases, the fact that it's far from trivial to figure out whether your script is portable or not, makes them not portable for practical intents and purposes. I would say that for most people and most use cases, shell scripts are write once and hope you never have to edit them again, and even knowing one way of comparing values may be problematic while another might not be is beyond the given pay grade.
- dredmorbius 2y ago
  You can of course test portability by testing, or simply writing, your script against a POSIX-only shell interpretation. It's a lot easier to change a shebang (#!/bin/ash -> #!/bin/sh) than to rewrite the full script during a firefight. One might even suggest "/bin/bash considered harmful".
  - Joker_vD 2y ago
    One also may suggest "/bin/sh considered harmful". Does the rest of the world have to suffer just because Solaris can't be arsed to upgrade its tooling (much of it is very tentatively POSIX-compliant anyhow) so they block any new additions to the /bin/sh features in the POSIX?
    - chasil 2y ago
      The dash shell compiles to 80k on an i386, which is viable for embedded applications. The POSIX shell was standardized in view of the original Korn shell, which could compile to 64k on Xenix 286. The functionality was reduced in an effort to increase code maintainability. Edit: "A lot of effort was made to keep ksh88 small. In fact the size you report on Solaris is without stripping the symbol table. The size that I am getting for ksh88i on Solaris is 160K and the size on NetBSD on intel is 135K. "ksh88 was able to compile on machines that only allowed 64K text. There were many compromises to this approach. I gave up on size minimization with ksh93." https://m.slashdot.org/story/16351 https://m.slashdot.org/story/16351
    - dredmorbius 2y ago
      <https://news.ycombinator.com/item?id=41682985 https://news.ycombinator.com/item?id=41682985> It's hardly just Solaris.
    - deleted 2y ago
      [deleted]
- pastage 2y ago
  This can be said of most programming, in Java, C++, golang, Pascal and Ruby I have been on projects that could not compile. The dependencies are so out dated a complete rewrite is easier. I do not find bash worse or better. You just do alot more with less lines in it.
- chasil 2y ago
  If you use arrays, you cannot use dash.
cmsj 2y ago
The correct solution here is to pick one of the following options: 1) Write a bash script and put /bin/bash in your shebang 2) Write a POSIX shell script and integrate checkbashisms into your editor. Neither is more correct than the other.
- chasil 2y ago
  3) #!/bin/dash
  - flir 2y ago
    #!/usr/bin/env dash I mean, if we're targeting portability...
- dredmorbius 2y ago
  I believe many Linuxes still symlink /bin/sh -> /bin/bash, so the shebang itself won't save you. Debian's assignment of /bin/dash as the default /bin/sh is relatively recent (at least for those who've been running Debian since the 1990s). I virtually exclusively write Bash scripts for my own use. I've been bit by bashisms however, and at the very least don't casually dismiss the concerns which are voiced against doing this. I'm also daily using systems which don't have a full Bash, and which really don't have the resources to run it (mostly storage, though other factors may be involved).
- yjftsjthsd-h 2y ago
  > Write a POSIX shell script and integrate checkbashisms into your editor. Suggestion: Use shellcheck. It will complain about bashisms if your script says #!/bin/sh and will also catch loads of other problems.

dredmorbius 2y ago

I've got sympathies with both sides of this argument. Bashisms are powerful, flexible, and occasionally performant. They're also non-portable, and you're apt to discover this whilst in an emergency situation with limited resources, most of all time. Having to edit shell scripts into POSIX conformance on a smartphone SSH session is No Bueno. There are an awful lot of systems which have either no, or old, Bash. Most prevalent of the latter is MacOS / OSX, which is now nagging me on each shell initialisation that the current supported standard is not bash but zsh. Scripts linked to /bin/bash will of course run, but the last update was version 3.2.57(1) if my system reports correctly. The most recent GNU Bash release is 5.3 according to <https://ftp.gnu.org/gnu/bash/ https://ftp.gnu.org/gnu/bash/>. And that's hardly the only old Bash floating around. On many systems, including many routers, DSL/cable modems, and other embedded devices, shell is some alternate variant (dash is /bin/sh on Debian, ash on RHEL's initrd IIRC, which last I fought with it was a script-only interpreter, not capable of running interactive commands, fucking annoying as hell). And there are still legacy Unix systems running Bourne, ksh, or other shells. Not to mention the phenomenal number of systems for which busybox provides much if not all of the userland environment, including /bin/sh. And is not bashism-capable. Ignoring POSIX works fantastically until it doesn't. Caveat scriptor.

chasil 2y ago
If you want the most powerful shell, ksh93 has the most features without doubt. Since David Korn retired, it has been adrift with few updates. The dash shell can be compiled with libedit to implement "set -o vi" (which is also POSIX), and is pleasant to use this way.
imtringued 2y ago
I don't know why someone would subject themselves to bash if the common argument in favour of it is a lie. People say that bash is already installed on the system. Then people like you point out that it isn't.
- dredmorbius 2y ago
  Bash is installed on my own primary system(s). And generally a quite recent version. When I'm coding my own utility scripts (or more likely: writing one-liners which may get reused through shell history, possibly eventually being memorialised as scripts), I'll make heavy use of bashisms for the reasons I've noted elsewhere: powerful, convenient, often performant. But if I'm inflicting those or other scripts on other systems I'm highly cognisant that not all systems have either a modern bash, or bash at all, and will either write POSIX-conformant scripts there, or remove bashisms from my own scripts. That is, availing myself to benefits whilst recognising limits to my approach. A key benefit of scripting in the shell language used most frequently is that one is highly familiar with it. Scripting-only languages tend to be less familiar. They're also less available (sed and awk being the principle exceptions, which are also mandated under POSIX, and for which GNU variants also have idiosyncrasies (I run into this on MacOS all the time, and tend to make use of GNU sed/awk there). Perl, Ruby, Python, Lua, node.js, Tcl, etc., have more capabilities, but are also unavailable on a large number of systems. (Often old or small systems. to be sure, but numerous all the same.)