🚀 go-pugleaf

>> Either PE broke login, or they broke execlp, or the permissions on your
>> shell script are not right ...

I just tried executing a shell script via login (by setting the shell field
of /etc/passwd to point to a file containing the following shell script:

     echo "This is a shell script"
     echo "it seems to be working"
     echo "now let's get a shell"
     /bin/sh

) and it worked fine.  I set the permissions to a+x on the shell script
file.  My guess is that they have the permissions set wrong.  However,
there's one other possibility...

Here's what execlp does (all variable names are fictitious, and only a
general algorithm overview is given):

	1) Get the value of the PATH environment variable into pv.

	2) If pv is empty, set pv to ":/bin:/usr/bin"

	3) [important] If the name given to execvp contains a "/" ANYWHERE
	   in the name, set the search path to null.  Otherwise, set the
	   search path to pv.

	4) For each component c of the search path, concatenate c with
	   the name given to execvp.  Try to execute this filename with
	   execv.  Handle various errors appropriately; in particular,
	   if ENOEXEC occurs, try executing /bin/sh giving it the file
	   name that got the ENOEXEC error.  If this also fails, return
	   a -1.  (This is always done at least once, so if the search
	   path is null the file name by itself will be executed, and
	   tried with the shell if the exec fails).

Now, step (3) above suggests one other possible problem; if the user gave a
file name like "extras/progname", where the full path of extras/progname is
/bin/extras/progname, making the assumption that /bin will be used in
searching for the file, the program would not be found.  Probably execvp
should check the FIRST character of the filename for a "/", not ANY character,
but it doesn't, so you have to give a full pathname if the name given to
execlp or execvp contains a slash, because no PATH searching
will be done in such a case.

However, I don't think PE "broke" login or execlp.

Note that the above algorithm is a fairly well-optimized one; from the manual
you might think it always calls the shell to execute the command, but it only
does so if a plain exec (with appropriate path searching) fails.

-------

Incidentally, looking at execlp I notice something interesting; execlp makes
assumptions about the way the stack is set up by the C compiler.  Specific-
ally, it assumes that a function call
	fcn(a,b,c,0);
will produce a vector corresponding to argv on the stack, so that &a gives
a pointer of type (char **) to an argv-style vector.  Having just read a
paper by Motorola on portability problems ("latent source bugs") which
Motorola found when it ported Unix to Exormacs, it occurs to me that this
is another latent source bug, just waiting to be found by someone who
changes the stack format for some reason.  It's a good thing our stacks are
made to model the PDP-11 stacks on our Unix systems!  Otherwise, execlp
WOULD fail.

[I won't post this reply to unix-wizards; I have a long-standing policy of
not posting to that conference due to the behavior of some of its contrib-
utors.  If someone wants to post a statement that "PE did not `break'
execlp or login" based on my comments, that's ok, but I'd prefer not to
get into any public dialogues with the `wizards' in that newsgroup.]
-- 
Full-Name:  J. Eric Roskos
UUCP:       ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail:    MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642

"Not that the story need be long; but that it will take a long time
 to make it short."  -- H. D. Thoreau