Re: Questions about the behavior for argv(0)
On Jun 4, 7:20 pm, Nate Eldredge <n...@vulcan.lan> wrote:
James Kanze <james.ka...@gmail.com> writes:
The answer for all of these is simple (and exactly like the
answer for Unix, so slightly portable): in both Unix and
Windows, the invoking process provides whatever it likes as
argv[0]. Which doesn't conform to either the C standard nor
the C++, but a conforment implementation of C or C++ isn't
possible under Unix or Windows.
I wouldn't say this makes it non-conformant. The C standard
says that "the string pointed to by argv[0] represents the
program name" (5.1.2.2.1 (2)). It does not further define
"program name". So one could argue that the string provided
by the calling process *is* the program name for that
particular run of the program.
The C++ standard says that it is the name used to invoke the
program, which is more restrictive:-).
(Of course, strictly speaking, conformance is always possible,
since it's always conformant for argv[0] to be simply "", an
empty string.)
Indeed, in the Unix world, this is the terminology people
actually use; the program's name is independent of filename of
its executable. ("If you run this program with the name
'foo', it does something; if you run it with the name 'bar',
it does something else.")
That's not quite the situation: under Unix, a file can have many
names, and the rule is if it is invoked with one name, it does
one thing, and if it is invoked with another, it does something
else. Normally, however, these are still names of the
executable file (although the case of aliases still exists).
There's also a convention in Unix that if the first character in
argv[0] is a '-', the program should consider itself a login
shell. And in this case, there really isn't any program with
that name on the disk.
The fact that the standard does not define "program name"
suggests to me that the authors intended to let the
implementation decide what the "program name" should be. This
seems very reasonable, since those details are clearly beyond
the scope of the standard. Note also the previous paragraph,
wherein the argv strings are described as having
"implementation-defined values".
Finally, I find it very unlikely that the standard authors
would knowingly include specifications that would make all
existing Unix and Windows implementations non-conformant, as
you seem to suggest they did.
An implementation has several possible solutions: it can always
make argv[0] an empty string, of course. Or it can document
that it is only conformant for programs which are invoked from
the Bourne shell (or one of a number of pre-defined shells which
do pass the right thing to argv[0]). In practice, although not
without drawbacks, I prefer the way Unix (and Windows) does it
to something that would be 100% conform, everywhere.
I'm also interested to know of an alternative method that
returns a consistent result. The following has been
suggested and I will investigate:
Call the Windows API GetModuleFileName(NULL, ...) to get
the fully qualified path of your .exe
That's what I use.
Note that under Unix, it is generally not possible to do this
reliably at all, so if you intend to port someday, you should
design your program in a manner that does not require this
information.
It's not possible to do it 100% reliably, but in practice, you
can probably get close enough for most uses. The goal, of
course, is to find related files: resources, text and messages,
etc.; if the user has created an environment confused enough
that you can't find the executable under Unix, then tough luck:
you output an error message and exit with an error status.
(FWIW: I actually had the code working under Unix before porting
it to Windows.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34