Date: Mon, 3 Aug 1998 17:13:07 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Michel de Ruiter <mdruiter AT cs DOT vu DOT nl>
cc: djgpp-workers AT delorie DOT com, dj AT delorie DOT com
Subject: Re: argv[0] behaviour.
In-Reply-To: <m0z3Jqx-000XepC@sloep06.cs.vu.nl>
Message-ID: <Pine.SUN.3.91.980803165826.3493D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


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.