Re: Changing argv[0] under Linux.

[DervishD <raul@pleyades.net>]

    Hi Jakob :)

> >     If execv doesn't do any magic with the supplied argv array, then
> > this should work.
> Yep, that's what I though.  Can anyone shoot this down?  ;)

    Not me ;)) The only problem would arise if the argv[0] passed to
exec is 511 bytes long but its strlen is low, because exec can choose
to copy the array to a new location (in fact, I think it does it...).

    If you provide a filled argv[0], and soon after the exec you
change it to a proper value, there is only a brief chunk of time
where argv[0] will have long and strange contents. It doesn't matter,
because you can use spaces and anyway this is not important.

[Code snippet... snipped] 
> Can anyone point out a problem in the above? I'd be happy to see it shot
> down, mainly because it's ugly - and I hate programs that mess with
> argv[0].

    I like your code ;))) I don't think it's ugly, on the contrary, I
find it quite elegant ;)) And I hate programs that mess with argv[0],
too. In fact, I'm against that, but I need it... You deserve an
explanation: it's a virtual console only init clone, and has a
builtin getty and login, and a builtin syslogd+klogd, too, all in
less than 17k... Well, due to the 'builtin nature' of this program,
we don't want ps show '/sbin/init' or just 'init' for the klogd
process, for example, or in the login process. We want 'ps' to show
'login' for the login process or 'klogd' for the klog builtin
emulator. That's all.

    By now I just assumed that at least I had four spare characters,
but this is not true anymore when testing, since I provided init=/i
to lilo, for example. And anybody can use that parameter and screw my
init totally, just for the sake of the proc string issue :((

    Your exec solution seems to be the easiest and cleanest one, and
should work, IMHO... I'm going to test right now ;))

    Thanks for your help.

    Raúl