Post History
Nobody likes it when their ‘how can I do this?’ questions are answered with ‘don’t do this’, but while an answer could be given that would probably work well enough most of the time for many use ca...
#1: Initial revision
Nobody likes it when their ‘how can I do this?’ questions are answered with ‘don’t do this’, but while an answer could be given that would probably work well enough most of the time for many use cases, the question itself is contradicted by how environment variables and `PATH` in particular are expected to work. An environment variable should not be presumed to be a static configuration value. It can be: * Dynamically computed when a user's login session begins * Modified by a user's shell (and a user may have different shells for different purposes) * Extended or modified by various other parent processes a user may be running (such as, as you're discovering, `sudo`!) Consider a Python virtualenv as an example. A virtualenv is a local copy of a Python installation that can be isolated from a system-wide Python, in order to facilitate installing different versions of Python packages or even the Python interpreter itself. It works by setting the `PATH` in the current shell to point to where it stores its own executables, but other shells and other processes aren't affected. A user who has entered a virtualenv will expect any of the tools they use to respect the `PATH` of the virtualenv. They would not want to run a script that then does something dodgy to read their ‘original’ `PATH` (whatever that even means, when `PATH` can be modified by several things between the user logging in and a shell prompt, some of which can be optional depending on things like whether the user is in a graphical session) and possibly run a Python interpreter that is not from the virtualenv they have entered. (Alternatively, if you are writing a script that requires a specific version of some utility such that you don't want to be subject to things like virtualenvs, your script should set its own `PATH` or refer to that utility by absolute path.) The right question to ask is not ‘what is this user's `PATH`?’, but ‘what is the ambient `PATH` in the context of my script when it is invoked?’. And the right approach to this problem, if your script depends on `sudo` to function, is for your script to invoke `sudo` itself after collecting what it needs from the ambient environment.
