54

I've noticed that basically no system I've ever worked with has /bin/sh as a real executable. It's always a symlink to dash, bash in POSIX mode, or something similar.

Why? What are the disadvantages of using the true, original /bin/sh? (Speed? Licensing?)

strugee
  • 14,951
  • 5
    You've only ever used Linux, right? I've only ever seen "sh as symlink" on Linux. – Greg Hewgill Nov 05 '13 at 20:45
  • @GregHewgill Don't recent versions of Solaris have sh symlinked to ksh? – Gilles 'SO- stop being evil' Nov 05 '13 at 23:08
  • 2
    @Gilles according to one of the answers, yes, since Solaris 11. it's linked to ksh. – strugee Nov 06 '13 at 19:16
  • 2
    @GregHewgill I've also used Darwin, which has it symlinked to bash, IIRC. – strugee Nov 06 '13 at 19:17
  • 8
    What do you mean by the original /bin/sh? The Thomson shell from Unix V1? The Bourne shell from Unix V7 that had no functions not comments...? The one in SysIII, SysV, Solaris, HP/UX, the ash reimplementation on BSDs? Nowadays sh is based on a standard which means we can have several implementations that will behave in a clear specified way as long as you use the standard syntax in your script. – Stéphane Chazelas Aug 18 '15 at 21:28

5 Answers5

39

I'd guess lack of features - no command history, no fancy redirection, no command line editing. BSD introduced csh the C shell for those reasons. Another factor is that the Genuine Bourne Shell was only recently available in open source form. Unless you licensed it, you couldn't distribute it. That put it out of reach for free-of-cost distros, and made it ideologically unpalatable for other distros, and *BSDs.

But the code is available now. You can take a look, compile it, give it a spin.

  • 54
    And then promptly switch back to whatever you were using before. – Ignacio Vazquez-Abrams Nov 05 '13 at 04:14
  • 3
    "lack of features" - why would this be a problem? you'd use it for scripting and then use something nicer, like bash or zsh for interactive user, right? – strugee Nov 05 '13 at 07:38
  • 24
    @strugee ""lack of features" - why would this be a problem? " Yes, good point... why do programmers use useless things like assembly/C/high level languages when anything you can do with them you can already do writing machine language directly? Fact is: features = increase in speed of development + increased maintainability = less costs = better Using sh is exactly like using bash except that it is: slower, programs are longer and it is harder to maintain. – Bakuriu Nov 05 '13 at 07:59
  • 10
    Its not really the lack of features but the fact POSIX mandates the sh command to run a POSIX compliant shell, what the legacy Bourne shell is not. While POSIX doesn't requires sh to be in /bin/sh, that's the most logical directory for it to be. – jlliagre Nov 05 '13 at 08:17
  • Why isn't the legacy Bourne shell POSIX-compliant? Or, rather, why did the POSIX committee choose to require features it didn't have? – Random832 Nov 05 '13 at 21:53
  • 4
    @Bakuriu command history and command line editing are both things that you wouldn't really need for a script. – strugee Nov 06 '13 at 00:52
  • 4
    @strugee Those aren't the only differences. For example sh doesn't have tilde and brace expansion, some built-ins are missing(e.g. pushd and popd, select) no arithmetic expansion. A lot of variables are missing, e.g. PIPESTATUS. – Bakuriu Nov 06 '13 at 07:19
  • 2
    True Bourne shell has no built-in arithmetic, no ((...)), no $(...) (which means you have to use `...`, which leads to really messy nesting and quoting). No function-local parameters, only globals. No arrays. No POSIX strings or here-strings. No process substitution. Even for noninteractive use in scripts, it is significantly inferior to bash/ksh/zsh. – Mark Reed Dec 11 '13 at 18:01
  • I have a lot fun using dash instead of bash, when I don't want to preserve history, but it took months to forget about pressing ctrl+L for clearing the screen, or other modern luxuries like the backspace key. – forgotstackxpassword Jul 26 '16 at 18:10
25

The statement in your question is incorrect. Solaris up to version 10 is providing the legacy true Bourne shell as /bin/sh. This was done not to break compatibility with old scripts that might fail with a different shell. This choice was very frustrating otherwise though.

Most if not all remaining Unix and Unix like releases, including Solaris 11, do provide a POSIX compatible shell as /bin/sh because POSIX mandates the sh command to launch a POSIX shell, not the legacy Bourne shell which is not compliant. /bin/sh is generally :

  • ksh88 or ksh93 on the commercial Unix implementations
  • a modified bash on OS/X (though it used to be zsh)
  • an ash or pdksh derivative on other BSDs
  • bash or dash on Gnu/Linux distributions.

It is not necessarily a link but can be a real executable on many systems but Gnu/Linuxes.

Interestingly, despite what states the most upvoted answer to your question, it is not the lack of features that lead distribution developers to install something different than the legacy Bourne shell in /bin/sh but the desire to be as POSIX compliant as possible, i.e. to behave like a Unix like OS. The fact the POSIX shell has more features than the legacy Bourne shell is only a side effect of this standard compliance goal.

It is also a fact some shells, notably bash, behave differently when called sh, and this mostly removes features from the shell, not the other way around.

jlliagre
  • 61,204
14

As far as I know the original Bourne shell couldn't be used by the BSDs and the GNU project, because of its license.

Back then the original Unix had no license and the GNU project needed a shell that was under the GPL so they used the bash.

The same thing is true for BSD4 the parent of all BSDs. Thanks to the AT&T lawsuit they needed to rewrite all source from the original Unix including the Bourne shell.

In the traditional BSD line, the Bourne shell was shipped until 4.3BSD-Reno (but not anymore with Net/2 and the following 4.4BSDs). For license reasons it was then substituted with the bourne-compatible, svr4-like sh by Kenneth Almquist (often called ash).

From FreeBSDs man sh

A sh command, the Thompson shell, appeared in Version 1 AT&T UNIX. It was superseded in Version 7 AT&T UNIX by the Bourne shell, which inherited the name sh.

This version of sh was rewritten in 1989 under the BSD license after the Bourne shell from AT&T System V Release 4 UNIX

So both projects were forced to not use the Bourne shell and settle for an true open source shell.

Raphael Ahrens
  • 9,771
9

There have been other problems. The Bourne Shell did use sbrk() instead of malloc() and this made it not very portable.

After the Bourne Shell had become OpenSource via OpenSolaris, I created a hafway portable version and later a really portable version by replacing sbrk() by malloc() with the help from Geoff Collyer (the same person that helped to avoid sbrk() in the Korn Shell).

The initial reason, why I made a portable version of the Bourne Shell is that I liked to make the History Editor I wrote for my "bsh" between 1982 and 1984 available in the Bourne Shell as well. Meanwhile, I ported most of the unique characteristics I wrote for "bsh" to the Bourne Shell.

This is among others:

  • Compiles and works nearly everywhere including Cygwin (nearly 2x faster than bash)
  • The history editor with a LRU ring buffer
  • builtin TERMCAP
  • Advanced aliases (global persistent aliases, local aliases, ....) and together with the "dosh" builtin, the Bourne Shell is the only Bourne Shell alike implementation that allows parameterizable aliases.
  • Support to edit complex aliases in the history editor in raw mode.
  • Access all 32 bits of the exit(2) code via .sh.* variables.
  • advanced automated timing with 6 digit resolution
  • pushd/popd/dirs
  • builtin "find"
  • Pipe from stderr
  • Using vfork() for better performance.
  • finally fixed all documented bugs from the SVr4 Bourne Shell, e.g. suspend always works in job control mode. ...

The online man page is at: http://schillix.sourceforge.net/man/man1/bosh.1.html The sources are part of the schily toolbox at:

https://sourceforge.net/projects/schilytools/files/

I recommend to use: http://sourceforge.net/projects/schilytools/files/schily-2015-08-18.tar.bz2 or a newer version.

P.S. I am interested in feedback

schily
  • 19,173
  • Hi Joerg. Why port them to the Bourne shell rather than a shell that had already been POSIXified like some BSD sh or pdksh? – Stéphane Chazelas Aug 18 '15 at 13:48
  • The Bourne Shell porting was a challenge as it does not use stdio. This was a similar challenge as taking the original csh source and make it compile by replacing the non-stdio printf written in VAX assembler. But I already added a lot of newer POSIX features to the Bourne Shell and I like to stay with the Bourne Shell on SchilliX in order to allow it to boot with / anr /usr on separate filesystems which is not possible with the Korn Shell. – schily Aug 18 '15 at 13:51
  • Also note that I wanted to verify that the speed of ksh is caused from using vfork(). Now that I converted the Bourne Shell to use vfork() is is exactly as fast as recent ksh versions. This is an experience you only get when starting with the original Bourne Shell source code. – schily Aug 18 '15 at 13:58
  • OK, but until you make that sh POSIX conformant, it's not likely to attract a lot of interest. I remember you asking on the austin group ML about the incompatibilities with POSIX of the Bourne shell, is it something you're working on (which would mean breaking backward compatibility wit the Bourne shell)? Also people (I at least) consider POSIX sh syntax a progress over the Bourne shell. Keeping calling your Bourne-derived shell the Bourne shell may send the wrong impression. How about bimsh (Bourne improved (ala vi/vim))? – Stéphane Chazelas Aug 18 '15 at 14:08
  • My Bourne Shell is already better than ksh in some aspects, e.g. implementing better aliases, pushd/popd/dirs and resource usilisation support based on modern UNIX features instead if what ksh does which is still SVr2 based. As you seem to be interested and skilled in the shell, I would like to get ideas on what you would like to see next in the Bourne Shell after reading: http://schillix.sourceforge.net/man/man1/bosh.1.html Note that so far, I have all new code #ifdef'd and some features (like stderr pipes) need to be switched on via set(1). – schily Aug 18 '15 at 14:14
4

It is linked to shells that provide 100% Backward compatibility. You don't lose anything that the original shell has but gain more features on top of it. There's no downside so why miss out on the new features? This is the same reason why /bin/vi is usually linked to vim.

JoelFan
  • 1,329
  • 6
    The downside is that people write scripts that work on their one system, thinking their script is compatible when it isn't. I once fixed almost a hundred Gentoo shell scripts that actually required bash but called /bin/sh. They all broke when I changed /bin/sh to be dash instead of bash. – Zan Lynx Nov 05 '13 at 23:23
  • 4
    "no downside" - speed. e.g. bash is much, much slower than dash – strugee Nov 06 '13 at 00:53
  • @strugee If you are looking for ms-range improvements speed in a shell, you're probably not using the right tool for the job. – Chris Down Nov 09 '13 at 09:18
  • 1
    @ChrisDown define "ms-range improvements"? – strugee Nov 10 '13 at 03:48
  • 3
    The POSIX sh syntax is not fully backward compatible with the Bourne sh syntax. For instance, IFS=,; rm file1,file2,file3 would remove those 3 files in the Bourne shell. That (silly) feature was removed in POSIX sh. There are dozens of subtle differences that could cause a script written for the Bourne shell to work differently with a POSIX sh. – Stéphane Chazelas Sep 28 '15 at 12:14