joe@petsd.UUCP (Joe Orost) (03/23/85)
>> Either PE broke login, or they broke execlp, or the permissions on your >> shell script are not right ... I had a "wizard" explain this to me. He said I could post this to the net: -------------------------------------------------- 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. -------------------------------------------------- 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
danny@itm.UUCP (Danny) (03/28/85)
In article <479@petsd.UUCP> joe@petsd.UUCP (Joseph M. Orost) writes: >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 stand corrected. Perkin-Elmer, I hereby formally apologize to you for the spreading of this untruth. In my defense, I can only say, that on an earlier version of this system (all derived from U*IX version 7) that I wanted uucico to run at nice -10. Placeing "/usr/lib/uucp/niceuucp" in /etc/passwd, as the last field, failed to execute. Calling it from .profile worked. Therefore, I assumed (and we all know about assume, don't we?) that it stayed broken. In the time-honored words of Peter Schekle, "Oops!". Danny -- Daniel S. Cox ({gatech|akgua}!itm!danny)