Bug 9235 - (bash -> sh) bash does not behave like standard Bourne Shell
(bash -> sh) bash does not behave like standard Bourne Shell
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
6.1
All Linux
low Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-08 13:38 EST by Q Enterix
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-09 15:16:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Q Enterix 2000-02-08 13:38:06 EST
(bash -> sh) bash does not behave like standard Bourne Shell

Bash Shell is a symbolic link to Bourne Shell by default, but it does not
behave the same. Some of shell scripts written for Bourne shell are broken,
because they expect to find "generic Bourne."

see simple example:

$ bash -c 'echo "\ntext\c"'
$ ksh -c 'echo "\ntext\c"'

There problem could be corrected by changing symbolic link to "sh" from
"bash" to "ksh" (pdksh), but this breakes startup init scripts written in
Bash and using "#!/bin/sh" in first line...

$ cd /etc/rc.d/init.d
$ grep \^#! *

apmd:#!/bin/sh
atd:#!/bin/bash
autofs:#! /bin/bash
crond:#! /bin/sh
dhcpd:#!/bin/sh
dtlogin:#!/bin/ksh
functions:#!/bin/sh
gpm:#!/bin/bash
halt:#!/bin/bash
httpd:#!/bin/sh
identd:#! /bin/sh
inet:#! /bin/sh
isdn:#! /bin/bash
keytable:#!/bin/sh
killall:#!/bin/bash
kudzu:#!/bin/sh
linuxconf:#!/bin/sh
lpd:#!/bin/sh
mars-nwe:#!/bin/sh
mcserv:#!/bin/sh
named:#!/bin/sh
netfs:#!/bin/bash
network:#!/bin/sh
nfs:#!/bin/sh
nfslock:#!/bin/sh
nscd:#!/bin/sh
nwclient:#!/bin/sh
pcmcia:#!/bin/sh
portmap:#! /bin/sh
routed:#! /bin/sh
rstatd:#! /bin/sh
rusersd:#! /bin/sh
rwalld:#! /bin/sh
rwhod:#! /bin/sh
sendmail:#!/bin/sh
single:#!/bin/sh
smb:#!/bin/sh
snmpd:#!/bin/bash
squid:#!/bin/bash
syslog:#!/bin/sh
vmware:#!/bin/sh
xfs:#!/bin/sh
ypbind:#!/bin/sh
yppasswdd:#!/bin/sh
ypserv:#!/bin/sh

The solution would be to make sure that all Bash scripts on the system
are using correct first line "#!/bin/bash"
Comment 1 Riley H Williams 2000-02-09 13:40:59 EST
The most obvious fallacy about this bug report is that it compares the action of
bash to ksh and then assumes that ksh and sh behave the same. The problem with
that fallacy is that sh itself behaves differently on different systems.

As an example of this, I tried the first example above on two different systems
I have access to that have what claims to be the standard Bourne shell, one a
Sun Solaris, the other an Irix, and they responded as follows:

 Sun: # sh -c 'echo "\ntest\c"'
 Sun:
 Sun: #

 Irix: # sh -c 'echo "\ntest\c"'
 Irix:
 testcIrix:

Quite clearly, the Irix doesn't understand \c and so just ignores the \ and
prints out the c, whereas the Sun actually understands it.

My argument here would be to state that as sh itself appears not to have a
standard implementation, there is no means by which any shell can claim to
conform to that non-existant standard...
Comment 2 Q Enterix 2000-02-09 15:16:59 EST
I have check on Solaris and Irix also. Actually, Bourne Shell on Solaris
does it correctly in interactive mode, but on Irix is messed up.

Points taken.

I pointed this in the first place only as an example. That inconsistency between
the shells (and Bourne shells) is _the_problem_. I can be open on my first issue
with symbolic link to "sh," but I _still_ think all scripts should be revised
and correct syntax in the first line should be kept (#!/bin/*sh) to eliminate
any possible confusions.
Comment 3 Bernhard Rosenkraenzer 2000-10-20 08:19:05 EDT
We're trying to use /bin/bash where bash specific features are used; the scripts that use /bin/sh shouldn't have any bash specific things in them.

If you notice any problems in the scripts that have /bin/sh, please report them to the package owning the scripts, because that's where a fix is needed - 
it's not a bug in bash.

Note You need to log in before you can comment on or make changes to this bug.