Shell standardization (for c.std.unix)

[Chuck Karish]

Submitted-by: karish at mindcraft.com (Chuck Karish)

In article <17400 at cs.utexas.edu> gwyn at smoke.brl.mil (Doug Gwyn) wrote:
>In article <17155 at cs.utexas.edu> jack at cwi.nl (Jack Jansen) writes:
>>I don't see any problem in the shell reading the first line and
>>checking it for #!/bin/sh.
>
>Shells that have done this (e.g. some csh implementations on UNIX System V)
>have definitely caused problems.  For example, Most of my shell scripts
>start with #!/usr/5bin/sh to ensure System V semantics on BSD systems;
>however, on a genuine UNIX System V system I was expecting the script to
>be interpreted by /bin/sh (even if executed by csh).

It would seem that programmer expectations were more at fault here than
were the SysV shells.  The scripts he described were designed to
exploit a difference in the behavior of shells on different systems.  I
don't understand why it worked, though.  On some older SysV-based
systems I've used, scripts that start with the '#' character are
interpreted as csh scripts no matter what follows the '#'.

Some systems that honor "#! /bin/whatever" do not default to csh if the
file starts with just "#".

The need for a hard-coded path makes scripts that depend on the "#!"
mechanism non-portable. "/usr/5bin/sh" is the right path for a shell
with full SysV functionality on a Sun.  On a DEC system, the
incantation is "/bin/sh5"; on other systems, the correct name might be
"/usr/usg/sh" or "/bin/bsh".  Perhaps what we need is a standard set of
non-filename identifiers for shells.

Creative use of links can help alleviate this problem on existing
systems.

I would be more optimistic that the adoption of the 1003.2 standard
would solve this problem if I hadn't already seen the many different
ways that vendors have isolated 1003.1 behavior in compatibility
modes.  Operating system standards won't live up to their full
potential until they're accepted as the default interfaces.

To change the subject a little, what features of modern sh
implementations cause scripts written for the BSD sh to fail?  I
presume there's a reason that BSD vendors don't install a SysV sh in
/bin.  Followups on this point should probably go to comp.unix.shell.
-- 

	Chuck Karish		karish at mindcraft.com
	Mindcraft, Inc.		(415) 323-9000

Volume-Number: Volume 22, Number 90