On Wed, Aug 21, 2013 at 2:02 AM, Rich Felker <dal...@aerifal.cx> wrote: > POSIX mandates the current uClibc behavior: > > invoked the sh utility using execl() as follows: > > execl(<shell path>, arg0, file, arg1, ..., (char *)0); > Actually, I'm thinking about the next paragraph,
The argument arg0 should point to a filename that is associated with the process being started by one of the exec functions. As I'm not a native English speaker, I hope I didn't get it wrong. I think either "process being started" shall be <shell path>, so arg0 shall be "/bin/sh", or arg0 is simply implementation-defined. The statement seems vague to me. For example, user executes the follow shell command, $ ./foo.sh a b c Shell calls execvp ("foo.sh", ["foo.sh", "a", "b", "c"]) where arg0 is "foo.sh", arg1 is "a" arg2 is "b" arg3 is "c" and execvp returns ENOEXEC, so the <file> is executes as if, by the standard, execlp ("/bin/sh", [arg0, "foo.sh", "a", "b", "c"]) where <shell path> is "/bin/sh" file is "foo.sh" arg1 is "a" arg2 is "b" arg3 is "c" So what shall the value of arg0, _the process being started_, be? uClibc sets arg0 to "foo.sh", while glibc, BSD libc and bionic libc set arg0 to "/bin/sh". I'm not really sure which one is right. > > Hopefully there is some other way around this; I think it needs to be > fixed in busybox, not uClibc... If, by the standrd, arg0 is not necessary <shell path>, I agree busybox should fix it, not uClib to workaround it. > Rich Wei-cheng _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc