Newsgroups: comp.lang.c Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: Contents of argv[0] Message-ID: <1989Aug15.162445.20267@utzoo.uucp> Organization: U of Toronto Zoology References: <9002@attctc.Dallas.TX.US> Date: Tue, 15 Aug 89 16:24:45 GMT In article <9002@attctc.Dallas.TX.US> jls@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@zoo.toronto.edu