Follow up: How to write a Linux virus

It may not be common for programs to be found in other places, but when it is done, it may be done for very good reasons. Therefore /usr/bin/env should be the strongly preferred mechanism for all scripts.

The use-case I am familiar with is configuration management and site-wide installations. The calling process has PATH constructed to collect a carefully managed set of versions of programs together, and scripts work well when they respect the PATH.

Environment Modules (http://modules.sourceforge.net/) is a very usable approach. (The tcl implementation is the better version, in my experience.)

It comes down to control: the script user knows their needs and their environment, more so than the script writer. In a multi-user, multi-machine environment, a surprising wide variety of tool collections can be made to work, often on a monoculture of old distributions: in my case, RHEL3 until recently.

In a hardware or silicon engineering environment, being able to freeze and re-use a versioned collection of tools some years after they were originally current is very useful. I think it also has applicability in a software engineering environment.

Please, do use #!/usr/bin/env, even if it doesn't seem well-motivated on a single-user short-lived installation.

It is required for execve to work, as xdg-open is itself a script.