Contents of argv[0]

Henry Spencer henry at utzoo.uucp
Wed Aug 16 02:24:45 AEST 1989


In article <9002 at attctc.Dallas.TX.US> jls at attctc.Dallas.TX.US (Jerome Schneider) writes:
>Both K&R and H&S document the argv[0] string as "the name of the program".
>This definition doesn't seem to mandate (or exclude) the presence of a path
>component in the string.  A few  *nix programs use rindex() or strrchr() to
>scan for '/', implying (to me at least) that _some_ implementations consider
>"name" to include such information...

Unix will generally give you the name the user referred to the program by,
which usually does not contain a path component but sometimes does.

>Are there any (proposed) standards for argv[0] syntax? ...

X3J11 (Oct 88 draft, but the content hasn't changed significantly) says:

1. Argc might be 0, in which case there need not be an argv[0].

2. For argc>0, argv[0] must be a modifiable pointer to a modifiable string.

3. For argc>0, argv[0] points to a string that "represents the program name",
	unless the program name is not available, in which case it's the
	empty string.  If dual-case strings are not available, the string
	shall be in lowercase.

Period.  All this applies only to a "hosted" environment; in a "freestanding"
environment, e.g. a program running a microwave oven, all bets are off.

POSIX 1003.1 constrains argv[0] to exist [I think] and point to "a filename".
Beyond that, POSIX just more or less says that argv[0] gets whatever
exec* gave for the 0th argument.  On that happy day when we actually
see a 1003.2 standard, it may say something more specific about what
argv[0] is for a program run by a standard shell.
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry at zoo.toronto.edu



More information about the Comp.lang.c mailing list