argv[0] handling

John Tytgat John.Tytgat at
Tue Jun 14 15:59:52 PDT 2005

In message <20050614125751.GI5969 at>
          Theo Markettos <theo at> wrote:

> On Tue, Jun 14, 2005 at 01:26:52PM +0100, Alex Waugh wrote:
> > 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.
> A rather extreme case is busybox, which does the job of 101 standard Unix
> tools and works out which one you asked for via argv[0].  I'm guessing this
> is generally done with hard/soft links but we could do it with aliases which
> wouldn't break argv[0] (unless people do things like */foo )
> [does exec*() handle RISC OS aliases?]

You mean Alias$* system variables ? It should because in the end the
exec argument gets OS_CLI'ed so it is RISC OS figuring out whether it
is a module * command, an alias, a FS based program, etc. using the
current Run$Path.

> > I think canonicalising it if it contains any . : < > $ characters, 
> > otherwise leaving it as it is, should be good enough for most cases.
> The aliases case above makes that a little more dangerous: what does
> exec("cat") do?  (which could exist as a built in *command, an alias and an
> executable all at the same time).

Whatever the OS_CLI resolving rules are.

> What about exec(".")?

As there is by default an Alias$., I presume its value get used (unless
there is a module *. defined).

> > I'd be tempted to leave making it configurable until someone finds a 
> > case where it is needed.
> I think probably making it configurable and the default being keep the
> status quo is safest...

I'm not in favour of inventing configuration settings of which is not clear
which real problems they solve.

To be honest the argv[0] issue is for most programs a non issue so let its
solution be as simple as possible for the few cases where it is necessary
and not over-engineer the whole thing.

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at                             ARM powered, RISC OS driven

More information about the gcc mailing list