Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

[Carl Fredrik Hammar]

On Sat, Feb 27, 2010 at 09:40:55PM +0600, Ivan Shmakov wrote:
>  > Giving them new names, e.g. _hurd_exec_path, might be a good idea to
>  > avoid incompatibilities,
> 
> FWIW, this seems to be the most reasonable solution to me.
> 
> But note that there's a slight terminology issue here:
> 
> --cut: (standards) GNU Manuals --
>    Please do not use the term "pathname" that is used in Unix
> documentation; use "file name" (two words) instead.  We use the term
> "path" only for search paths, which are lists of directory names.
> --cut: (standards) GNU Manuals --

Right, I forgot about that little rule.

>  > but eventually we'll want to deprecate the original versions.
> 
> Do I understand it correctly that the filename is only necessary
> when the exec server is called to execute a #! script?  If so,
> could there be uses for non-file name versions of these calls?
> These versions, however, should at some point of time be amended
> to fail when asked to execute a script.
> 
> (Though I could imagine that these versions may be found to have
> only marginal uses, and so be discarded entirely.)

Yes and no.  Currently, #! is the only case where the filename is needed
(AFAIK), but there is nothing stopping anyone from inventing new binary
formats that also relies on this information.

I don't think non-filename versions are necessary.  If you don't know
the filename you can always use a `/dev/fd/$n' path to an open file
descriptor, which is what the exec server currently does if it can't
figure out the name.

>  > I don't know how this should be handled in general; you'll want to
>  > get a more authoritative answer from Thomas Schwinge, or possibly
>  > Olaf Buddenhagen or Samuel Thibault.
> 
> Well, I think that no one will object to the OP patching the
> version in his own Git repository?  Anyway, the solution should
> be tested with respect to the original problem.

Yes, of course.  I might of gotten ahead of things here.  :-)
This is only relevant for the version that is to be committed into
mainline.

Regards,
  Fredrik