[I've unsuccessfully tried to submit the comment via the Web
interface at http://savannah.gnu.org/bugs/, thus I'm posting it
to the list instead.]
>>>>> Carl Fredrik Hammar <invalid.nore...@gnu.org> writes:
[...]
> The reason argv[0] is expanded is because it is passed as an argument
> to the interpreter, otherwise the interpreter can't find it.
> Because the exec server is passed an already opened port to the
> executable, it doesn't know the path used to open the executable. It
> has to reconstruct it instead.
I don't know the details on how it's done in Hurd, but shouldn't
the exec* () library functions pass the whole argv[] (including
argv[0]) to the server?
I'm not sure what the standards say on that matter, either, but
the GNU Libc manual reads:
--cut: (libc) Executing a File --
-- Function: int execv (const char *FILENAME, char *const ARGV[])
The `execv' function executes the file named by FILENAME as a new
process image.
The ARGV argument is an array of null-terminated strings that is
used to provide a value for the `argv' argument to the `main'
function of the program to be executed. The last element of this
array must be a null pointer. By convention, the first element of
this array is the file name of the program sans directory names.
*Note Program Arguments::, for full details on how programs can
access these arguments.
--cut: (libc) Executing a File --
Please note that since FILENAME is a completely distinct
argument from ARGV, ARGV[0] may, most of the time, contain
garbage, without breaking the programs being called in any way.
> Also, ``./foo bar'' gets me `bar' in Linux not `./bar'. Are you sure
> you got `./bar' in this case?
Perhaps, there was ‘.’ in the PATH's value? (Which is known to
be a gigantic security hole, BTW.)
[...]
--
FSF associate member #7257
pgpvYdIHZXwVY.pgp
Description: PGP signature
