This article will discuss the issues related to the /usr/local/products area on many Fermilab systems; the history of how and why it was established, the unanticipated problems with the approach, and the varied directions we are taking to move away from that solution.
#!/usr/products/xxx/current/bin/executableto make a script for that product executable, and many folks started in that direction.
Then the problem became that there were many more /usr/local areas than there were products areas, and in fact we did not know where all of the different /usr/local areas were.
A system where the software had not been configured did not operate properly. Also there was a tendency for /usr/local to be destroyed (and re-created without /usr/local/products) when systems were re-installed or upgraded, once again causing products in the central area to be cease working on some systems.
Because of these problems, we are moving away from using the /usr/local/products area, and actively pursuing other means of solving these problems.
#!/usr/bin/env interpreter(where interpreter would be "perl" for perl scripts, "python" for python scripts, etc.) The "env" program will run the first copy of "interpreter" on your command search path, and your scripts are executable.
This solution has drawbacks in areas where getting the product setup is difficult, and it also limits the ability to turn on extra interpreter command-line options in the #! line of the script.
Where it is usable, the UAS group recommends this as the best solution for most cases, because your scripts also work in environments like CERN's ASIS, where products are essentially "always set up", or where non-ups versions of products are installed in a "usual" place on a university or other off-site system.
#!/bin/sh . /usr/local/etc/setups.sh setup myproduct exec mycommand "$@"is a script which uses the /usr/local/etc/setups.sh script to get the ups "setup" facilities imported, sets up a given product, and runs a given command with the command line arguments given to the script. This approach works well when the setup time is not critical.
This approach has drawbacks in that it is not usable on many off-site systems, even ones running UPS, where /usr/local may not be writable by the folks maintaining ups products.
For these sorts of products, the UAS group is providing "trampoline" executables, installing them in /usr/local/bin where possible, which get the appropriate path names stuffed into them at "ups configure" time (e.g. when a product is first declared), and can then be installed in any place you want. They have the benefit that you can put
#!/path/to/trampolinein a script, and a the script is then executable. This gives you back the flexibility to put in command line options in your #! lines, and reduces the setup overhead, but provides maintenance effort for the product maintainers.