Mail Archives: djgpp-workers/1998/08/03/10:13:29
On Mon, 3 Aug 1998, Michel de Ruiter wrote:
> Command | Somewhere in %PATH% | In current directory
> --------+-------------------------------+-----------------------------
> argv0 | e:/djgpp/bin/argv0.exe | j:/share/mcsim/argv0.exe
> make | e:\djgpp\bin/argv0.exe | argv0.exe
>
> So, not "all reverse slashes are replaced with unix-style slashes",
> when run from `make'. Also, when run from the current directory, the
> path to the executable fails. Is this a bug in libc.a somewhere? A
> feature? Or is it a documentation bug?
This is a known behavior: the crt0 flag only affects argv[0] that came
from the DOS command line; it does not affect command lines passed by
DJGPP programs to their children. And when a program is found in the
current directory, `system' and `spawnXX' don't pass a fully-qualified
path name in the child's argv[0].
Whether this is a bug or a feature depends on your point of view. I'm
not sure whether the crt0 feature is at all important, since it doesn't
(and IMHO cannot) solve the basic problem of special syntax of DOS path
names that requires special, different from Unix, code in every program
which looks at its argv[0]. So I'd guess that it is mostly unused.
OTOH, the startup code that deals with that works that way since the days
of v1.x, is extremely complicated, took many iterations to get right, and
so it is not clear to me that it should be changed in this case.
I agree that it should be documented, but at the time I was afraid that
documenting it will confuse people even more, as a user cannot easily
tell which method will be chosen by `system' and `spawnXX' to pass the
command line in every case.
> args are set back to DOS-defaults if !proxy is used
Where did you see that? I don't think this is done in the startup code.
- Raw text -