[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Emilio Pozuelo Monfort
Subject: Re: [PATCH 1/3] Add a new exec_exec_file_name RPC
Date: Wed, 02 Jun 2010 01:15:26 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100515 Icedove/3.0.4

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>

main (int argc, char **argv)
  char *arg[] = { argv[1], NULL };
  execv (*arg, arg);
  perror ("execv");
  return 1;

$ cat glib-dev-fd-sh
echo "\$0: $0"

Then do ./glib-dev-fd.c glib-dev-fd-sh


reply via email to

[Prev in Thread] Current Thread [Next in Thread]