On Fri, 3 Nov 2017 18:54:16 +0000 Christopher Baines wrote: > However, I think that the file wrapping approach has advantages for > visibility. Maybe it could be tweaked to keep ensure the wrapper script > has the same name as the script its wrapping, e.g. when wrapping foo, > replace foo with a bash script, and move the real script > to .wrapped-bin/foo. We already try to do just that, by using the -a flag when exec'ing the real program from the wrapper. But... > the environment activation feature of our “conda” package currently > fails. This is because the “deactivate” shell script is wrapped in > another shell script. This leads to the actual shell script to be > called “.deactivate-real”. The script compares the value of “$0” with > the expected name “deactivate”. This fails so conda misbehaves. ... it doesn't behave correctly when the "real" program is shebang-interpreted. It works fine for compiled programs. E.g. our "emacs-25.3" is a wrapper that sets XDG and GTK env vars, but top/htop/ps show the proper "emacs-25.3". OTOH we have the "deactivate" example from Ricardo, which is a shell script, and e.g. youtube-dl, whose --help output includes "Usage: .youtube-dl-real ...". So the interpreters are not passing on the intended zeroth argument. IMHO it'd be nice to find some way to fix that. A while ago I had looked into patching Perl libraries/programs. But like Hartmut mentioned for python, I noticed after some research that patching perl paths would be nontrivial, and would require a perl parser to determine where and how to patch the library paths correctly. 2c, `~Eric