Bug 9235 - (bash -> sh) bash does not behave like standard Bourne Shell
Summary: (bash -> sh) bash does not behave like standard Bourne Shell
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 6.1
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-08 18:38 UTC by Q Enterix
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-09 20:16:35 UTC
Embargoed:


Attachments (Terms of Use)

Description Q Enterix 2000-02-08 18:38:06 UTC
(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 18:40:59 UTC
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 20:16:59 UTC
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 12:19:05 UTC
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.