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
