1

I have an ubuntu machine with default shell set to bash and both ways to the binary in $PATH:

$ which bash
/bin/bash
$ which sh
/bin/sh
$ ll /bin/sh
lrwxrwxrwx 1 root root 4 Mar  6  2013 /bin/sh -> bash*

But when I try to call a script that uses the inline file descriptor (that only bash can handle, but not sh) both calls behave differently:

$ . ./inline-pipe
reached
$ bash ./inline-pipe
reached
$ sh ./inline-pipe
./inline-pipe: line 6: syntax error near unexpected token `<'
./inline-pipe: line 6: `done < <(echo "reached")'

The example-script I am referring to looks like that

#!/bin/sh
while read line; do
if [[ "$line" == "reached" ]]; then echo "reached"; fi
done < <(echo "reached")

the real one is a little bit longer:

#!/bin/sh
declare -A elements
while read line
do
    for ele in $(echo $line | grep -o "[a-z]*:[^ ]*")
    do
        id=$(echo $ele | cut -d ":" -f 1)
        elements["$id"]=$(echo $ele | cut -d ":" -f 2)
    done
done < <(adb devices -l)
echo ${elements[*]}
peterh
  • 11,875
  • 18
  • 85
  • 108
fragmentedreality
  • 1,287
  • 9
  • 31

3 Answers3

3

When bash is invoked as sh, it (mostly) restricts itself to features found in the POSIX standard. Process substitution is not one of those features, hence the error.

chepner
  • 497,756
  • 71
  • 530
  • 681
  • Yes, refering standards was always very powerful argument to destroy something, which is better as these standards. Especially for the standards, which were "invented" by a _committee_. – peterh Nov 25 '13 at 14:53
  • 2
    @MaXX I'm afraid nothing is clearly understandable in your comment, outside perhaps you seem to rant about standards. – jlliagre Nov 25 '13 at 15:32
  • Please read my next (long) answer, too - probably it makes the things clearer. My opinion is that 1) a very large proportion of the standards were developed by actually incompetent groups ("committee"), 2) too many good ideas fail because these standards. – peterh Nov 25 '13 at 15:34
  • 2
    @Maxx Neither point is relevant to the question as stated, the answer to which would be the same even if the standard was developed in a perfect world and made everyone happy. If every shell restricted itself to features in the standard, there would only *be* one shell: the standard. Having non-standard features is a way to test new ideas; the good ones can be considered for inclusion in the standard in the future. No one stops you from using non-standard features, but one should understand and be prepared to accept the loss of portability if one does. – chepner Nov 25 '13 at 15:44
  • I think, the difference between our opinions is, what we see as default. You see default, what is a standard. I see default, what is a reachable best. – peterh Nov 25 '13 at 15:48
-1

Theoretically, it is a feature of bash: if you call as "sh", it by default switches off all of its features. And the root shell is by default "/bin/sh".

Its primary goal is the security. Secondary is the produce some level of compatibility between some shells of the system, because it enables the system scripts to run in alternate (faster? more secure?) environment.

This is the theory.

Practically goes this so, that there are always people in a development team, who want to reduce and eliminate everything with various arguments (security, simplicity, safety, stability - but these arguments are going somehow always to the direction of the removal, deletion, destroying).

This is because the bash in debian doesn't have network sockets, this is because debian wasn't able in 20 years to normally integrate the best compressors (bz2, xz) - and this is because the root shell is by default so primitive, as of the PDP11 of the eighties.

peterh
  • 11,875
  • 18
  • 85
  • 108
  • 1
    I'm afraid you are missing what is the primary purpose of standards in general, and Unix/POSIX ones in particular. In that case, it is to **allow** developers to create scripts that are portable between compliant platforms. There is no hidden agenda. – jlliagre Nov 25 '13 at 17:53
  • I wish you had right, but I've s..ed so much already. Especially the network removal from the bash, and the gzipped debs made my opinion such as it currently is. – peterh Nov 25 '13 at 23:01
  • 1
    Both of the current and previous Debian releases have network support enabled in bash and this feature is not disabled when bash is run in POSIX mode. I don't see how gzipped debs, whatever that means, relate to bash/sh behavior or POSIX standards. – jlliagre Nov 26 '13 at 00:08
-2

I believe sh on ubuntu is actually dash which is smaller than bash with fewer features.

Cole Tierney
  • 9,571
  • 1
  • 27
  • 35