Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Questions about the behavior for argv(0)

Reply
Thread Tools

Questions about the behavior for argv(0)

 
 
C Guy
Guest
Posts: n/a
 
      06-02-2009
The function signature for main is:

int main (int argc, char *argv[], char **envp)

argc tells you how many argv[] there are.

argv[0] is the name of the executable - the name of the executable
containing main().

Under Win-XP, I've noticed that argv[0] does not include the full
filespec when invoked within a command shell. By filespec, I mean the
full path and the full name of the program file - including suffix (ie -
..exe).

What I am seeing in argv(0) is just the file stem - as typed by the
user.

Eg, from a command shell, if I invoke "example" from c:\hello\there\, I
am seeing argv[0] return simply "example". In other words, exactly what
the user typed, not the full and complete filespec.

If I perform the same command in, say, a command prompt in win98,
argv(0) returns "c:\hello\there\example.exe" (the full and complete
filespec).

Maybe I'm dreaming, but I could swear that once upon a time that from a
command prompt on XP that I would see the same thing as I see on win98.

When launched from explorer (under XP) argv(0) seems to behave as I
expect.

Did XP always exhibit this behavior?

How does NT and 2K behave in this regard?
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      06-02-2009
C Guy <(E-Mail Removed)> writes:
> The function signature for main is:
>
> int main (int argc, char *argv[], char **envp)


The envp parameter is non-standard.

> argc tells you how many argv[] there are.


Close enough. argv[argc] is a null pointer.

> argv[0] is the name of the executable - the name of the executable
> containing main().


All the C standard requires is that it "represents the program name".
In more detail:

If the value of argc is greater than zero, the string pointed to
by argv[0] represents the program name; argv[0][0] shall be the
null character if the program name is not available from the host
environment. If the value of argc is greater than one, the strings
pointed to by argv[1] through argv[argc-1] represent the program
parameters.

Both behaviors you describe are consistent with this requirement.

> Under Win-XP, I've noticed that argv[0] does not include the full
> filespec when invoked within a command shell.

[...]
> When launched from explorer (under XP) argv(0) seems to behave as I
> expect.
>
> Did XP always exhibit this behavior?
>
> How does NT and 2K behave in this regard?


That's a Windows question, not a C (or C++) question. If you don't
get an answer from microsoft.public.vc.mfc, try
comp.os.ms-windows.programmer.win32.

Followups redirected, dropping comp.lang.c and comp.lang.c++.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      06-03-2009
On Jun 3, 1:51 am, Keith Thompson <(E-Mail Removed)> wrote:
> C Guy <(E-Mail Removed)> writes:
> > The function signature for main is:


> > int main (int argc, char *argv[], char **envp)


> The envp parameter is non-standard.


The envp parameter makes the entire line implementation defined.
So he really does need to ask in an implementation specific
forum.

> > argc tells you how many argv[] there are.


> Close enough. argv[argc] is a null pointer.


> > argv[0] is the name of the executable - the name of the executable
> > containing main().


> All the C standard requires is that it "represents the program
> name". In more detail:


> If the value of argc is greater than zero, the string pointed to
> by argv[0] represents the program name; argv[0][0] shall be the
> null character if the program name is not available from the host
> environment. If the value of argc is greater than one, the strings
> pointed to by argv[1] through argv[argc-1] represent the program
> parameters.


> Both behaviors you describe are consistent with this requirement.


The C++ standard differs slightly here. (I'm reading this in
comp.lang.c++. Yet another problematic cross-posting, although
I guess one could be forgiven for not realizing the C and C++
are different here.) In C++, ``[...] and argv[0] shall be the
pointer to the initial character of a NTMBS that represents the
name used to invoke the program or "".'' Of course, I'm not
sure what "name used to invoke the program" means if I've
invoked it by clicking on some icon. And neither Windows nor
Unix are really conform in this regard---in both, it's
relatively simple to start a program with a totally arbitrary
string in argv[0]. (In Unix, for example, some programs will
prepend a '-' to the program name.)

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
C Guy
Guest
Posts: n/a
 
      06-03-2009
James Kanze wrote:

> The C++ standard differs slightly here. (I'm reading this in
> comp.lang.c++. Yet another problematic cross-posting, although
> I guess one could be forgiven for not realizing the C and C++
> are different here.)


Is there a better newsgroup than microsoft.public.vc.mfc to post this
question in then?

comp.os.ms-windows.programmer.win32 has been suggested. Any others?

Others have written:

> argv[0] does not have to be a full path name nor even a file name.


I'm more interested in knowning why the behavior of argv[0] is different
(on an XP machine) when a program is invoked within a command shell vs
windows explorer.

I'm also interested to know why the behavior of argv[0] is NOT different
on a win-98 box under the same two conditions.

I'm also interested to know if the behavior I currently see for argv[0]
on an XP box has always been there, or if some service pack, update or
patch is the reason for the current behavior.

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

 
Reply With Quote
 
jameskuyper
Guest
Posts: n/a
 
      06-03-2009
C Guy wrote:
> James Kanze wrote:

....
> > argv[0] does not have to be a full path name nor even a file name.

>
> I'm more interested in knowning why the behavior of argv[0] is different
> (on an XP machine) when a program is invoked within a command shell vs
> windows explorer.
>
> I'm also interested to know why the behavior of argv[0] is NOT different
> on a win-98 box under the same two conditions.
>
> I'm also interested to know if the behavior I currently see for argv[0]
> on an XP box has always been there, or if some service pack, update or
> patch is the reason for the current behavior.
>
> 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


Since neither the C standard nor the C++ standards impose sufficiently
strict restrictions on the value of argv[0] for your needs, every
single one of those questions is more appropriatedly directed to a
windows-specific newsgroup than to either comp.lang.c or comp.lang.c+
+.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      06-04-2009
On Jun 3, 2:34 pm, C Guy <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > The C++ standard differs slightly here. (I'm reading this in
> > comp.lang.c++. Yet another problematic cross-posting, although
> > I guess one could be forgiven for not realizing the C and C++
> > are different here.)


> Is there a better newsgroup than microsoft.public.vc.mfc to
> post this question in then?


> comp.os.ms-windows.programmer.win32 has been suggested. Any
> others?


I'm not sure; the comp.os.ms-windows.programmer is the hierarchy
where I'd go.

> Others have written:


> > argv[0] does not have to be a full path name nor even a file
> > name.


> I'm more interested in knowning why the behavior of argv[0] is
> different (on an XP machine) when a program is invoked within
> a command shell vs windows explorer.


> I'm also interested to know why the behavior of argv[0] is NOT
> different on a win-98 box under the same two conditions.


> I'm also interested to know if the behavior I currently see
> for argv[0] on an XP box has always been there, or if some
> service pack, update or patch is the reason for the current
> behavior.


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'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.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Nate Eldredge
Guest
Posts: n/a
 
      06-04-2009
James Kanze <(E-Mail Removed)> 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. 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.")

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.

>> 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.
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      06-04-2009
On June 4, 2009 13:20, in comp.lang.c, Nate Eldredge ((E-Mail Removed))
wrote:

> James Kanze <(E-Mail Removed)> writes:

[other attributions lost prior to this post]
>>> 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.


Indeed. In my experience, the usual reason for a Windows programmer to
complain about Unix not providing the full pathname (through whatever
mechanism) of the executable is that the programmer intends to use the
supplied path in a manner not compatible with Unix system configuration
and/or usage. Typically, the Windows programmer wishes to continue to use
the Windows convention of having program configuration and data files
reside in the same directory as the program executable, which is contrary
to the spirit and often to the configuration of a Unix standard
environment.

I won't debate on the rightness or wrongness of this mechanism here, but I
will say that, in general, programmers either need to write programs for
portability (and not depend on /any/ of the platform and language-specific
features available to them), or they need to write for /specific/
platforms. Porting "portable" code (like code written exclusively to the C
standard) is easy and needs only a recompilation for the target
environment; porting "platform specific" code is hard, needs
platform-specific substitutions, and often /really needs/ (but is seldom
acted apon) a complete rearchitecting.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------


 
Reply With Quote
 
BobF
Guest
Posts: n/a
 
      06-04-2009
Nate Eldredge wrote:
> 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.")


Which Unix world? It's been a while, but IIRC the command typed at the
Unix prompt had to match an actual filename.

Using your example, I would need two shell scripts (files), one named
'foo' and the other named 'bar' to invoke a different *binary* with
different args to get different behavior between the two runs.

However, the scripts themselves are executable ... if you had said
'binary' instead of 'executable' it would make more sense ... to me.
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      06-04-2009
On June 4, 2009 13:36, in comp.lang.c, BobF ((E-Mail Removed)) wrote:

> Nate Eldredge wrote:
>> 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.")

>
> Which Unix world? It's been a while, but IIRC the command typed at the
> Unix prompt had to match an actual filename.


But, with Unix, two (or more) different filenames can point to the same
file. Thus, a Unix executable file can have multiple names, and can test
argv[0] to see /which/ name it had been called for execution.


> Using your example, I would need two shell scripts (files), one named
> 'foo' and the other named 'bar' to invoke a different *binary* with
> different args to get different behavior between the two runs.
>
> However, the scripts themselves are executable ... if you had said
> 'binary' instead of 'executable' it would make more sense ... to me.


The technique works for both executable binaries and executable shell
scripts. To me, it makes more sense to refer to 'executables'
than 'binaries' in the context of Unix filename/file linkage. OTOH, in the
context of C programming, it would make more sense to refer to 'binaries',
as C is seldom treated as an interpreted language or a shell script.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Questions about the behavior for argv(0) C Guy C++ 18 06-05-2009 12:58 PM
tkinter questions: behavior of StringVar, etc Alan G Isaac Python 14 03-30-2009 04:25 PM
Questions about sending 'transaction attribute behavior across entities. R Paley VHDL 2 11-20-2004 02:37 PM
Re: Questions....questions....questions Patrick Michael A+ Certification 0 06-16-2004 04:53 PM
undefined behavior or not undefined behavior? That is the question Mantorok Redgormor C Programming 70 02-17-2004 02:46 PM



Advertisments