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
> Presently, argv 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 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 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 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, 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 Waugh alex at alexwaugh.com
PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/
More information about the gcc