Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

[Emilio Pozuelo Monfort]

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