On Wed, Aug 21, 2013 at 2:02 AM, Rich Felker <[email protected]> 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
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
