The Filesystem Hierarchy Standard (FHS) has this to say: If /bin/sh is Bash, then /bin/sh should be a symbolic or hard link to /bin/bash since Bash behaves differently when called as sh or bash. pdksh, which may be the /bin/sh on install disks, should likewise be arranged with /bin/sh being a symlink to /bin/ksh. The use of a symbolic link in these cases allows users to easily see that /bin/sh is not a true Bourne shell.
The de-facto standard location of the C-shell is /bin/csh. A C-shell or equivalent (such as tcsh), if available on the system, should be located at /bin/csh. /bin/csh may be a symbolic link to /bin/tcsh or /usr/bin/tcsh. -- http://www.pathname.com/fhs/2.1/fhs-3.1.html HTH, --Jeff > Peter Donald <[EMAIL PROTECTED]> wrote: > > > Some systems apparently link /bin/sh to tcsh > > Must have missed that post, but I think this is just wrong. > > Too many scripts out there assume that /bin/sh is Bourne shell > compatible. Any vendor shipping with a /bin/sh that was not a Bourne > shell would surely get toasted. > > On all Unix systems I've ever worked with (including C-Shell based > systems like HP/UX and Solaris) /bin/sh has been a Bourne shell. > > > and we were using basyh specific features. > > The scripts should work with any Bourne shell (if they don't, we have > to fix *that*). > > What features are that? Unfortunately I don't have access to anything > but Linux or FreeBSD ATM, so I cannot spot the problems easily - but > it should be a high priority to fix this and I'll be happy to tackle > it. > > Finally switching to /bin/bash surely doesn't help. The scripts > probably work with a Korn shell (which is /bin/sh on AIX). Even if a > system admin cares to install Bash, it will probably end up in > /opt/bin or /usr/local/bin or something. > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
