Hi, On 05/19/2017 01:35 PM, Freddy Rietdijk wrote:
> 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. The problem with such an environment variable is that it's inherited by child processes, who might get confused. (E.g. some code might run both in a wrapped and unwrapped context, so it wouldn't be able to rely on $NIX_PROGRAM_NAME unambiguously.) But maybe $NIX_PROGRAM_NAME can be used only in the case where one wrapper script calls another, so the final wrapper can unset it. However, if we have wrapper scripts detecting that the wrapped program is also a wrapper script, we might as well eliminate the execve into the next wrapper (thus preserving the original argv[0]). > This, however, doesn't solve the issue with nested wrappers yet I think in general a) wrappers should be avoided; and b) nested wrappers should *definitely* be avoided. Wrappers cannot really be avoided for the "delayed composition" use case (like firefox-wrapper), but in such a case perhaps the inner wrapper can be eliminated. For example, if the inner wrapper is used to set $PYTHONPATH, this can be moved into the underlying Python script by setting sys.path at the start. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
