running a simple command line tool

[Johnny Rosenberg]

2012/2/23 Avi Greenbury <lists at avi.co>:
> CJ Tres wrote:
>> On 02/23/2012 05:40 AM, Avi Greenbury wrote:
>> > CJ Tres wrote:
>> >
>> >> Running basic smoketest.
>> >> smoketest.sh: 12: [[: not found
>> >> smoketest.sh: 18: [[: not found
>> >> smoketest.sh: 26: function: not found
>> >> Error found.  Leaving run.11199 in place.
>> >> Unable to execute command: 'sh test.sh'
>> >
>> > This looks like it's down to a naughty developer :)
>> >
>> > [[ is a 'bashism' (so-called because it's something that exists in
>> > bash but not in the 'sh' that it's a development from).
>> >
>> > The command 'sh test.sh' passes the 'test.sh' script to 'sh' which
>> > is a shell. Normally and historically it's a link to /bin/bash but
>> > modern Ubuntus and Debians use dash instead (in the interests of
>> > speed). [[ doesn't work in dash, so the test script fails on that
>> > error and the install aborts.
>>
>>
>> Running echo $SHELL returns /bin/bash on this install - Natty.
>
> Yeah, that's the default shell for your user. /bin/bash should always
> be bash, the iffy bit is where /bin/sh goes. It used to go to the
> bourne shell, before bash (the 'bourne again' shell, it's successor)
> was written. After that, it became common to make /bin/sh simply a link
> to /bin/bash since bash's features are a superset of the bourne shell's
> - something expecting the bourne shell will work in bash.
>
> A few releases of Debian (and so Ubuntu) ago, it was agreed
> that /bin/sh would instead be a link to dash, which is a good deal
> smaller than bash.

I wonder why they did that. Why not just include sh and use it as is?
If someone want to use dash, include that too. How hard can it be to
type ”#! /bin/dash”?
Is sh so extremely big that there is a point to not include it in the
distribution?


Kind regards

Johnny Rosenberg
ジョニー・ローゼンバーグ

> It's still a superset of the bourne shell, so
> anything that only requires the bourne shell will still work, but it's
> a different, and smaller, superset than bash.
>
> The problem is that a lot of people had come to assume that /bin/sh was
> bash, not the bourne shell, and when you try to run something that's
> got bashisms that are not present in dash (like the '[[' construct) in
> dash you get a syntax error.
>
> The error message tells you what command was run:
>  Unable to execute command: 'sh test.sh'
>
> So, we can find out what's run when we execute 'sh':
> root at donkey:~# which sh
> /bin/sh
> root at donkey:~# ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 2011-05-03 16:04 /bin/sh -> dash
> root at donkey:~#
>
> And you can see that it's a symlink to dash (that's what the '->' syntax
> means - the fact it just says 'dash' means it's in the same directory,
> so /bin/dash).
>
> Now, you *could* bodge it by repointing that symlink, but that's not a
> great idea in case things call that expecting dashisms that aren't in
> bash. What *should* happen is that when a script needs bash it is passed
> to bash, not sh. This is something that should really be fixed in those
> test scripts in that installer.
>
> --
> Avi