Hi Roland,
On 02/06/10 00:29, Roland McGrath wrote:
> wrt new RPC: sorry, I skipped the earlier discussion.
> What is this for?
No problem. Let me quote myself:
> Basically the problem is that in some cases the exec server can't find the
> file
> name of the file being executed (when it's a script), and then makes a hack
> passing /dev/fd/N to the interpreter.
>
> I tried to fix it with heuristics such as "if the file name contains no
> slashes,
> then it's relative" and passing just a flag to the exec server to avoid
> needing
> to create new RPCs, but that's not enough, since a call like
> execv("foo",{"bar",
> NULL}) (i.e. filename != argv[0]) should work too. So the only option is to
> pass
> filename to the exec server, and just use that.
>
> So this patch adds two new RPCs: exec_exec_file_name RPC and
> file_exec_file_name
> one. Then libc can use exec_exec_file_name in hurdexec.c.
This is me trying to solve the problem in hurdexec.c when it tries to look for
ARGV[0] in $PATH, which may or may not be correct. So we need to pass the
filename in a file_exec call to stop guessing and just calling it with the
interpreter instead of doing the /dev/fd/N trick.
A test case:
$ cat glib-dev-fd.c
#include <stdio.h>
int
main (int argc, char **argv)
{
char *arg[] = { argv[1], NULL };
execv (*arg, arg);
perror ("execv");
return 1;
}
$ cat glib-dev-fd-sh
#!/bin/sh
echo "\$0: $0"
Then do ./glib-dev-fd.c glib-dev-fd-sh
Cheers,
Emilio
