3 ms·

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

by 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

by rascul 3y ago

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