[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1114

--- Comment #4 from Guy Harris <guy@xxxxxxxxxxxx> 2011-11-21 16:46:47 PST ---
Does "FHS-compatible system" mean "system on which "/bin/sh" runs a
Bourne-compatible shell" here?

I'm not sure what they mean by

    For example bash behaves differently when called as sh or bash. The use of
a symbolic link also allows users to easily see that /bin/sh is not a true
Bourne shell.

as a rationale for

    If /bin/sh is not a true Bourne shell, it must be a hard or symbolic link
to the real shell command.

What the bash man page says on my system is

       If  bash  is  invoked  with  the name sh, it tries to mimic the startup
       behavior of historical versions of sh as  closely  as  possible,  while
       conforming  to the POSIX standard as well.  When invoked as an interac-
       tive login shell, or a non-interactive shell with the  --login  option,
       it  first  attempts  to read and execute commands from /etc/profile and
       ~/.profile, in that order.  The  --noprofile  option  may  be  used  to
       inhibit  this  behavior.  When invoked as an interactive shell with the
       name sh, bash looks for the variable ENV, expands its value  if  it  is
       defined,  and uses the expanded value as the name of a file to read and
       execute.  Since a shell invoked as sh does not attempt to read and exe-
       cute  commands from any other startup files, the --rcfile option has no
       effect.  A non-interactive shell invoked with  the  name  sh  does  not
       attempt  to  read  any  other  startup files.  When invoked as sh, bash
       enters posix mode after the startup files are read.

       When bash is started in posix mode, as with the  --posix  command  line
       option, it follows the POSIX standard for startup files.  In this mode,
       interactive shells expand the ENV variable and commands  are  read  and
       executed  from  the  file  whose  name is the expanded value.  No other
       startup files are read.

which sounds as if the intent is that bash, when run as /bin/sh, is as close to
"a true Bourne shell" as possible while still conforming to POSIX (if POSIX
specifies behavior other than traditional Bourne shell behavior, you're
unlikely to find on modern UN*Xes /bin/sh shells that offer traditional Bourne
shell behavior in the places where that differs from POSIX behavior).

So my inclination is:

    if a shell script will work with any POSIX-compatible Bourne shell,
hardcode /bin/sh, as even on Cygwin you're probably not going to find a modern
system on which you can run or develop for Wireshark where there's no /bin/sh;

    if a shell script uses bash extensions or otherwise works *only* with bash,
hardcode /bin/bash (although the FHS doesn't require it, and neither does POSIX
or, as far as I know, any other UN*X standard.

The version of the configure script built with the version of autoconf on my
machine, when trying to pick CONFIG_SHELL, searches /bin, followed by /usr/bin,
followed by the directories in $PATH, for any of sh, bash, ksh, and sh5, and
then tries all the ones it finds, followed by whatever's in $SHELL if set, in
order.  That has an extremely high probability of finding /bin/sh, and looks as
if it'll probably reject anything that's not even trying to be a
Bourne-compatible shell (e.g., a C-shell-compatible shell).  CONFIG_SHELL is
what replaces @SHELL@.

So what we have now for idl2wrs will almost certainly do the right thing;
however, all of the other *.sh files just hardcode /bin/sh or /bin/bash in the
#! line (except for ltmain.sh, but I think that's generated by libtool, which
is presumably clueful enough not to be hosed by csh/tcsh users) and aren't
generated from a .sh.in file.  I'd vote for hardcoding /bin/sh.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.