[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #28934] execve(path, args) should take path as a a relative pat
From: |
Carl Fredrik Hammar |
Subject: |
Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes |
Date: |
Sat, 27 Feb 2010 18:45:32 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
- [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Emilio Pozuelo Monfort, 2010/02/19
- [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Emilio Pozuelo Monfort, 2010/02/19
- [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Carl Fredrik Hammar, 2010/02/24
- [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Emilio Pozuelo Monfort, 2010/02/26
- [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Carl Fredrik Hammar, 2010/02/26
- [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Emilio Pozuelo Monfort, 2010/02/26
- [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Carl Fredrik Hammar, 2010/02/26
- Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Ivan Shmakov, 2010/02/27
- Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes,
Carl Fredrik Hammar <=
- Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Ivan Shmakov, 2010/02/26
- Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes, Carl Fredrik Hammar, 2010/02/27