Bug 21315
| Summary: | Shells often behave oddly when executing shell scripts | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Robert Watson <rwatson> |
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.1-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
> Shells appear to behave oddly when executing shell scripts in a number > of situations. > (1) When the kernel discovers that the interpreter used is another > interpreter, it generally returns ``Exec format error'' (ENOEXEC). > However, when csh and sh find themselves in the same situation, they > don't return that error, they execute the script using their own > interpreter. In the case of sh, POSIX says that it should do this. If sh gets ENOEXEC or equivalent when it tries to execute something, it should execute the file as a shell script. Only if the file is not a text file may sh refuse to execute it, writing an error message and returning an exit status of 126. (Our sh does not use this exception, resulting in messages like '1: Syntax error: "(" unexpected' when trying to execute an ELF binary for a different architecture.) > (2) When in single-user mode, the sh shell appears to assume that any > script it runs should be executed using its own interpreter, not the > interpreter at the top of the file. In multi-user mode, this appears > to work fine. I have no idea about this, but it could have something to do with ENOEXEC as well. In particular, when this PR was written, ld-elf.so.1 was in /usr/libexec, so unavailable when /usr was not mounted. -- Jilles Tjoelker State Changed From-To: open->feedback Should this PR still kept open? State Changed From-To: feedback->closed Feedback timeout. |
Shells appear to behave oddly when executing shell scripts in a number of situations. (1) When the kernel discovers that the interpreter used is another interpreter, it generally returns ``Exec format error'' (ENOEXEC). However, when csh and sh find themselves in the same situation, they don't return that error, they execute the script using their own interpreter. (2) When in single-user mode, the sh shell appears to assume that any script it runs should be executed using its own interpreter, not the interpreter at the top of the file. In multi-user mode, this appears to work fine. Fix: Not attached. How-To-Repeat: (1) $ cat /tmp/test1 #!/tmp/test2 echo This is test1, meant to execute using test2 $ cat /tmp/test2 #!/tmp/test1 echo This is test2, meant to execute with test1 $ /tmp/test1 This is test1, meant to execute using test2 $ /tmp/test2 This is test2, meant to execute with test1 $ I.e., executing test1 resulted in sh executing it, instead of ENOEXEC. Similarly with test2. Neither resulted in a recursive call, which is good. This seems like a poor failure-mode -- it's inconsistent with the kernel execve() implementation's failure mode, and it runs things when you would hope that it wouldn't (always bad). (2) Boot to single user mode, select /bin/sh as the shell, and attempt to execute a shell script relying on csh features.