Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!decwrl!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: execvp
Message-ID: <11952@sun.uucp>
Date: Thu, 22-Jan-87 22:42:33 EST
Article-I.D.: sun.11952
Posted: Thu Jan 22 22:42:33 1987
Date-Received: Sat, 24-Jan-87 00:02:31 EST
References: <452@bobkat.UUCP>
Sender: news@sun.uucp
Distribution: na
Lines: 31
Summary: No, that bug is long-gone

> According to the ("exec") "man" page,
> 
> 	If execvp is called to execute a file that turns out to be a 
> 	shell command file, and if it is impossible to execute the
> 	shell, the values of argv[0] and argv[-1] will be modified
> 	before return.
> 
> This seemed very strange to me.  Which "argv"?  Why does it mess with
> argv[-1]??
> ...
> In short I can't cause this "bug" to manifest itself; does it really
> exist?

Nope.  This same claim is in the V7 manual page.  It may have been
true back then; I don't have V7 source handy to check.

The 4.2BSD and S5 code do the same thing if the file is a shell
script.  They build a new argument list, whose first entry is "sh",
whose second entry is the name of the file that it found, and whose
subsequent entries are the 1st through Nth arguments (i.e., argv[1]
through argv[argc-1]).  My pure guess is that if this bug ever
existed, it was because some version of "execvp" *didn't* make a copy
of the argument list, but just smashed argv[0] with the name of the
file and argv[-1] with "sh" and fed this somewhat spurious argument
list to "execv".  Needless to say, smashing argv[-1] is violently
anti-social, since it's probably some random piece of user data.

Given that the 4.2BSD and S5 code are basically the same, I suspect
that the fix was in some version of UNIX from Research that predates
both of them.  A likely candidate for this version would be V7; it
may be that the documentation, as usual, trailed the code.