On Wed, Aug 21, 2013 at 12:42:57AM +0800, Wei-cheng Wang wrote: > Hi, > > When execvp executes the file and gets NOEXECV, it shall execute > a command interpreter as if the process is invoked by sh, and the > argv[0] shall point to the filename being started. Therefore, > a script file without hashbang (#!) is still executed by sh utility. > > However, currently uClibc set argv[0] to be the filename of the script > itself instead of the name of shell, e.g., "/bin/sh", and it is > inconsistent with the behaviors of other libc (e.g., BSD libc, glibc, > bionic libc) and how Linux kernel passed interpreter as argv[0] in > binfmt_script. Although it’s not mandatory in terms of POSIX.1, but > busybox relies on argv[0] for "sh" applet to be run.
POSIX mandates the current uClibc behavior: There are two distinct ways in which the contents of the process image file may cause the execution to fail, distinguished by the setting of errno to either [ENOEXEC] or [EINVAL] (see the ERRORS section). In the cases where the other members of the exec family of functions would fail and set errno to [ENOEXEC], the execlp() and execvp() functions shall execute a command interpreter and the environment of the executed command shall be as if the process invoked the sh utility using execl() as follows: execl(<shell path>, arg0, file, arg1, ..., (char *)0); where <shell path> is an unspecified pathname for the sh utility, file is the process image file, and for execvp(), where arg0, arg1, and so on correspond to the values passed to execvp() in argv[0], argv[1], and so on. > Without this patch, busybox complains "foo.sh: applet not found" > when executing a shell script without hashbang. > > Any comment? Hopefully there is some other way around this; I think it needs to be fixed in busybox, not uClibc... Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
