Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!stuart
From: stuart@cs.rochester.edu (Stuart Friedberg)
Newsgroups: comp.unix.questions
Subject: Re: \"+\" filename -> /bin/sh !
Message-ID: <3375@sol.ARPA>
Date: Mon, 19-Oct-87 15:28:47 EDT
Article-I.D.: sol.3375
Posted: Mon Oct 19 15:28:47 1987
Date-Received: Tue, 20-Oct-87 20:27:51 EDT
References: <9844@brl-adm.ARPA> <3351@sol.ARPA> <6583@brl-smoke.ARPA>
Organization: U of Rochester, CS Dept., Rochester, NY
Lines: 50
Summary: interaction between csh, exec, and sh; and sh vs. sh -i

In article <6583@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <3351@sol.ARPA> ken@cs.rochester.edu (Ken Yap) writes:
> >	/bin/sh +
> >and get an interactive sh.
> Any Bourne shell that does that is badly broken!

Ken and I played with this last night.  It is *not* that /bin/sh is
broken.  "+" is treated by sh the same way as "-", as a flag prefix.
(See the section of the manual on "set".) When, after processing a list
of flags, it finds no arguments left it (by default) starts an
interactive shell.  That is, "/bin/sh +" behaves just like "/bin/sh".

We can explain the originally posted behavior as an interaction of
several features.  First note the odd scenarios (they really happen):

1)		2)		3)
csh% +		csh% + +	csh% + date
$		<the date>	date: date: not found

4)		5)		6)
sh$ +		sh$ + +		sh$ + date
<the date>	<the date>	<the date>

Notice that in all cases, /bin/sh does the expected thing.  So, the
problem is in the interaction of csh, exec, and sh.

(1) Csh execs "+".  The kernel finds no good magic number, so actually
execs a /bin/sh giving it an argument list of "/bin/sh", "+".  The sh
parses its arguments, finds nothing left after processing the flags,
and (by default) becomes an interactive shell.

(2) Csh execs "+". The kernel ... giving it an argument list of
"bin/sh", "+", "+".  The sh parses its arguments, *apparently*
treats "+" exactly as a solitary "-", and treats the second "+"
as a script name.  It spawns a subSHELL with argument list
"sh", "-i" to process "+".

(3) Csh execs "+".  The ... list of "/bin/sh", "+", "date".  The sh ...
spawns a subSHELL with arg list "sh", "-i" to process "date", which
can not be found in the current directory.  Hence the error.  Note
the subshell identifies itself as "date" rather than "sh".

(4-6) Sh execs "/bin/sh" with arglist "sh", "-i" to process "+" and its
various arguments.  Because the shell is set up to do interactive
processing, the name of the "input" file is not subject to command line
processing.  The interesting question is how sh detects that "+" should
be processed as a script, because it is clearly not execing "+".  Does
it check for magic numbers before calling exec?  (I suppose)

Stu Friedberg  stuart@cs.rochester.edu