argv[0] handling

Alex Waugh alex at alexwaugh.com
Tue Jun 14 05:26:52 PDT 2005


Peter Naulls wrote:
> We've briefly mumbled about this in the past, but it's time for a
> revisit.
> 
> Presently, argv[0] is just the literal value passed from RISC OS.  It
> may contain a RISC OS path name, or RISC OS path variables, etc.   This
> means that programs that use argv[0] as the basis of their display can
> often do odd things.  It's possible to see "<Obey$Dir>.progname" as a
> program's title.  Or a full RISC OS path name as a bash prompt as
> programs attempt to trim to a Unix leafname.

If the program is run as a result of an exec call, then it would be 
possible to get SUL to pass argv[0] to the new program as whatever was 
specified to exec. This wouldn't help if the program wasn't started by 
an exec call though.

> This is clearly easily fixed with OS_FSControl 37 and unixfy, which I've
> just put into my build.  Without wanting to add nth degree
> configurability, does anyone thing that this might not always be
> appropriate?   In particular, this will result in programs which are
> just called with a leaf name always ending up with the full path.  And
> of course, pathnames in argv[0] will always be in Unix form.
> Heuristics may be sensible here.

I have a feeling that there are a few programs that change their 
behaviour based on argv[0], but I can't think of any examples at present.
I think canonicalising it if it contains any . : < > $ characters, 
otherwise leaving it as it is, should be good enough for most cases.

> Bear in mind that any handling like this will have to be either a system
> variable or a weak symbol, since this occurs before main() is called,
> and therefore beyond the control of the runtime riscosify flags.

I'd be tempted to leave making it configurable until someone finds a 
case where it is needed.


Alex

-- 
Alex Waugh                                           alex at alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/





More information about the gcc mailing list