If a Python script is run, then `sys.argv[0]` is set to the script name (or path, depending on platform). Some scripts use this name or path to start a new instance of itself. Unfortunately, exec -a doesn't set `sys.argv[0]`. Therefore, when running a wrapped Python script, `sys.argv[0]` points not to the wrapped script, but to the original one.
On Mon, May 22, 2017 at 9:41 AM, zimbatm <zimb...@zimbatm.com> wrote: > Hi Freddy, > > Can you expand a bit on why this is a problem? If a program is executed > using python I would expect this to be reflected in the process name. Argv0 > would contain a path to python and argv1 the path to the script. > > Cheers, > z > > On Fri, 19 May 2017, 12:35 Freddy Rietdijk, <freddyrietd...@fridh.nl> > wrote: > >> Hi, >> >> When we create a wrapper we use `exec -a` so that the wrapped program >> uses the name of the original program. This isn't respected by all >> programs, e.g. Python ignores this. If I am correct this is the case with >> all interpreters. How do we handle this with other interpreters? >> >> Currently we 'solve' the issue for Python by patching the scripts setting >> `sys.argv[0]` to the original script name, including the full path. This is >> sufficient for scripts that call themselves, however, it is troublesome >> when such a script is wrapped in another derivation, because when the >> script now calls itself, it will call the unwrapped version. >> >> Therefore, I propose we set an environment variable `NIX_PROGRAM_NAME` >> that the scripts check for. To prevent creating yet another `wrapProgram` >> variant I propose we extend `wrapProgram` to always set this variable. >> >> This, however, doesn't solve the issue with nested wrappers yet, because >> if we would use `set`, it would still refer to the name passed by the >> innermost wrapper. Either we try and update wrappers, or, which has my >> preference, we do not use `set` but use `prefix` and make the script pick >> the last item from the list. >> >> What do you think? I like to also refer to the following gist where I've >> been documenting some of the issues and how we can rewrite the Python infra >> to solve those issues. >> https://gist.github.com/FRidh/c3e974e34eac738405af699786b462d5 >> >> >> Freddy >> _______________________________________________ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> https://mailman.science.uu.nl/mailman/listinfo/nix-dev >> >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev