joe@petsd.UUCP (Joe Orost) (03/22/85)
I found this on "net.unix-wizards". Please answer this if you can. I looked at "login.c" and it does call "execlp". In article <556@rlgvax.UUCP> guy@rlgvax.UUCP (Guy Harris) writes: >> In article <503@rlgvax.UUCP> guy@rlgvax.UUCP (Guy Harris) writes: >> >Sorry, that *will* work on V7 (and 4.xBSD, and Sys3, and SysV) systems, >> >... >> Sorry, Guy, on our Perkin-Elmer 3210 running "edition7" (used to be "unix") >> with a few Berkleyisms (vi, more, 1K disk blocks) login *will not* >> execute a shell script...I sure wish it would.... > >Then you should yell at P-E; the code in the V7/S3/S5/4.xBSD/whatever "login" >uses "execlp" to run your login shell, which will execute shell scripts >(as long as the shell script has the execute bit set). It's successfully >worked with the S5 and 4.2BSD "login"s. Either P-E broke "execlp", or they >broke "login", or the permissions on your shell script are wrong, or the >shell script is broken. >-- > Guy Harris > {seismo,ihnp4,allegra}!rlgvax!guy regards, joe -- Full-Name: Joseph M. Orost UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!joe ARPA: vax135!petsd!joe@BERKELEY US Mail: MS 313; Perkin-Elmer; 106 Apple St; Tinton Falls, NJ 07724 Phone: (201) 870-5844 Location: 40 19'49" N / 74 04'37" W
jer@peora.UUCP (J. Eric Roskos) (03/22/85)
>> 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