Khimenko Victor wrote:
> > Because reading argv[0] is not a hack at all. The location of argv[0]
> > will never change.
>
> Are you sure ?
We can define it to be so :-)
> > There is no dubious overwriting of argument or environment string
> > space, and no dubious limits are assumed or broken.
> >
> There just very strange limitation that program can change it's arguments
> but can not change number of arguments...
This is only for /proc/PID/cmdline. You only need 1 argument, though it
is a convenient bonus that if you change argv[0] without clearing
argv[1], you'll change the name of the program while keeping the
existing arguments.
> > > If program want to change argument list or environment list
> > > then why notallow to do exactly this ?
> >
> > I can't think of any reason why a program needs to change its
> > environment list.
> >
> Hmm. Your programs are doing this all the time. sh scripts, etc.
> There are even few functions to do so (even POSIX ones!!!). Of course it's
> not clear how important is to know if environment is changed. But if we
> should not care about environment then why there are /proc/<number>/environ
> at all ???
I've always expected ps to show the environment that was passed to the
program, not the current environment in the program. You make a good
point though. /proc/PID/environ will not show either, because it reads
from the program's environ string area which is like to be changed in a
not very predictable manner by putenv.
> > But an equally clean way, one that's convenient and AFAIK actually works
> > on some other operating systems is to permit a program to say `argv[0] =
> > "my new name";'.
> >
> AFAIK this way should work with my patch as well. It's just UGLY.
Ok. So the syscall part of your patch is redundent then :-)
btw, I can see now why you need some way for the change to envp by
putenv to be passed to the kernel. Otherwise /proc/PID/environ is
always wrong: it doesn't show the current environment and it doesn't
show the unmodified one either. It potentially shows rubbish.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:22 EST