Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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/Spec

* https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_sy...

* https://lists.debian.org/debian-release/2007/07/msg00027.htm...

* https://lwn.net/Articles/343924/

* https://www.debian.org/doc/manuals/debian-reference/ch12.en....



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.


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.


> 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


Lots of other shells overcome bash’s deficiencies. Hoping dash will be installed is just like hoping elvish will be installed - it probably won’t be.

To make any progress away from bash, we need to standardize on “all mature shells in the base system” (for some definition of ‘mature’) as default.


You are well out of date.

As I said, this was over a decade ago. The Debian Almquist shell has been a required part of the operating system for Ubuntu and Debian, and several (perhaps all) of their derivatives, for all of that time. They switched it over to a mandatory ("essential") package years ago.

The Almquist shell is the /bin/sh on NetBSD. A slightly variant Debian Almquist shell is the /bin/sh on FreeBSD. The Debian Almquist shell is in Core in Arch Linux (and Parabola Linux and Hyperbola Linux). The Almquist shell is the sh in busybox. The Almquist shell is the sh in MINIX 3.

One has to travel quite far to the likes of Illumos or OpenBSD or Toybox on Android to find an operating system where it's not in the box as a core part of the operating system. And on several of the ones where it is a core part, it's actually /bin/sh already.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: