4 ms·

> It coordinates programs… Sounds like a case for shells in general. No other script-execution tools make running other programs (and linking their inputs and

> It coordinates programs… Sounds like a case for shells in general. No other script-execution tools make running other programs (and linking their inputs and outputs) so simple. To overcome Bash’s problems, one can choose another shell. But I suppose you can’t just pick your personal favorite and script in its dialect, because then how would the human tasked with integrating the script into $wherever know which shells to have installed? You can stick with sh which is guaranteed to be installed, or bash (indeed an improvement over sh) which is nearly guaranteed to be installed.

mrspuratic 3y ago
More than a decade ago I needed a multi-platform way to manage Nagios client data collection (mostly) using whatever native tools were available, so I wrote one. bash, gawk and send_nsca were the only 3 binaries needed, and it ran well on 10 different *nixs (free and commercial) on Alpha, ARM, MIPS, SPARC, X86 and X86_64 platforms. Of course, after a decade of incremental tinkering I ended up with exactly what you anecdon't want: ~2500 lines of shell script and ~1000 lines of awk... LOC misleads of course, there were 15 modular plugins, so there was a lot of boilerplate, and this includes non-runtime ~1000 lines for install, self-test and sanity checks.
JdeBP 3y ago
Or one can learn the lessons that Debian learned over a decade ago, and Ubuntu almost two decades ago, about bashisms, maintainability, and performance; and script in at most the Debian Almquist shell, whatever fancy shell one may be using interactively. * https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh * https://wiki.ubuntu.com/DashAsBinSh/Spec https://wiki.ubuntu.com/DashAsBinSh/Spec * https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_system_shell https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_sy... * https://lists.debian.org/debian-release/2007/07/msg00027.html https://lists.debian.org/debian-release/2007/07/msg00027.htm... * https://lwn.net/Articles/343924/ https://lwn.net/Articles/343924/ * https://www.debian.org/doc/manuals/debian-reference/ch12.en.html#_posix_shell_compatibility https://www.debian.org/doc/manuals/debian-reference/ch12.en....
- rascul 3y ago
  Interesting that efficiency is cited as the main reason in several of those links. And here I see that dash starts up only .001 seconds faster then bash. Maybe things were different 15 years ago, I don't know. The other concerns seem to have a very simple solution: use bash in the shebang instead of sh if your script uses bashisms.
  - JdeBP 3y ago
    That was one of the counterarguments to a common straw man of the time. Changing the interpreter line was a valid route. If you choose to use Bashisms, the counterargument went, you just make that choice explicit; just as people who used Korn/Z/whatever shell idiosyncrasies already had to. As for efficiency, recall that there were hundreds of /bin/sh scripts in startup, administration, and everyday operation of the system, from all of the /etc/rc.d/ (sub)scripts through things in cron and build systems and package install/deinstall scripts to bunches of commands that were /bin/sh scripts under the covers. So multiply that difference by several orders of magnitude. Amusingly, this is to a major extent still true. On these operating systems systemd is nowadays parsing .INI files over and over with its own custom .INI file parser, instead of a chosen flavour of /bin/sh parsing shell scripts over and over with whatever (Bison/YACC) parser they were using. They haven't actually gone down the SunOS SMF (and s6) route of compiling things into a machine-readable database. And there are still lots of /bin/sh scripts elsewhere, as service management is only one of several areas. An interesting alternate history would have been if the Z shell had been /bin/sh on Debian and Ubuntu instead of the Bourne Again shell when this came up, and how much of a difference employing zcompile everywhere would have made.
    - rascul 3y ago
      > As for efficiency, recall that there were hundreds of /bin/sh scripts in startup, administration, and everyday operation of the system, from all of the /etc/rc.d/ (sub)scripts through things in cron and build systems and package install/deinstall scripts to bunches of commands that were /bin/sh scripts under the covers. So multiply that difference by several orders of magnitude. And one of the links leads to a savings of 1 second on an eeepc. Not very convincing. https://wiki.debian.org/DebianEeePC/Dash https://wiki.debian.org/DebianEeePC/Dash

mrspuratic 3y ago

More than a decade ago I needed a multi-platform way to manage Nagios client data collection (mostly) using whatever native tools were available, so I wrote one. bash, gawk and send_nsca were the only 3 binaries needed, and it ran well on 10 different *nixs (free and commercial) on Alpha, ARM, MIPS, SPARC, X86 and X86_64 platforms. Of course, after a decade of incremental tinkering I ended up with exactly what you anecdon't want: ~2500 lines of shell script and ~1000 lines of awk... LOC misleads of course, there were 15 modular plugins, so there was a lot of boilerplate, and this includes non-runtime ~1000 lines for install, self-test and sanity checks.

JdeBP 3y ago

Or one can learn the lessons that Debian learned over a decade ago, and Ubuntu almost two decades ago, about bashisms, maintainability, and performance; and script in at most the Debian Almquist shell, whatever fancy shell one may be using interactively. * https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh * https://wiki.ubuntu.com/DashAsBinSh/Spec https://wiki.ubuntu.com/DashAsBinSh/Spec * https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_system_shell https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_sy... * https://lists.debian.org/debian-release/2007/07/msg00027.html https://lists.debian.org/debian-release/2007/07/msg00027.htm... * https://lwn.net/Articles/343924/ https://lwn.net/Articles/343924/ * https://www.debian.org/doc/manuals/debian-reference/ch12.en.html#_posix_shell_compatibility https://www.debian.org/doc/manuals/debian-reference/ch12.en....

rascul 3y ago
Interesting that efficiency is cited as the main reason in several of those links. And here I see that dash starts up only .001 seconds faster then bash. Maybe things were different 15 years ago, I don't know. The other concerns seem to have a very simple solution: use bash in the shebang instead of sh if your script uses bashisms.
- JdeBP 3y ago
  That was one of the counterarguments to a common straw man of the time. Changing the interpreter line was a valid route. If you choose to use Bashisms, the counterargument went, you just make that choice explicit; just as people who used Korn/Z/whatever shell idiosyncrasies already had to. As for efficiency, recall that there were hundreds of /bin/sh scripts in startup, administration, and everyday operation of the system, from all of the /etc/rc.d/ (sub)scripts through things in cron and build systems and package install/deinstall scripts to bunches of commands that were /bin/sh scripts under the covers. So multiply that difference by several orders of magnitude. Amusingly, this is to a major extent still true. On these operating systems systemd is nowadays parsing .INI files over and over with its own custom .INI file parser, instead of a chosen flavour of /bin/sh parsing shell scripts over and over with whatever (Bison/YACC) parser they were using. They haven't actually gone down the SunOS SMF (and s6) route of compiling things into a machine-readable database. And there are still lots of /bin/sh scripts elsewhere, as service management is only one of several areas. An interesting alternate history would have been if the Z shell had been /bin/sh on Debian and Ubuntu instead of the Bourne Again shell when this came up, and how much of a difference employing zcompile everywhere would have made.
  - rascul 3y ago
    > As for efficiency, recall that there were hundreds of /bin/sh scripts in startup, administration, and everyday operation of the system, from all of the /etc/rc.d/ (sub)scripts through things in cron and build systems and package install/deinstall scripts to bunches of commands that were /bin/sh scripts under the covers. So multiply that difference by several orders of magnitude. And one of the links leads to a savings of 1 second on an eeepc. Not very convincing. https://wiki.debian.org/DebianEeePC/Dash https://wiki.debian.org/DebianEeePC/Dash