Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

71%
+3 −0
Q&A As root, how do I read another user's environment variables?

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...

posted 7mo ago by r~~‭

Answer
#1: Initial revision by user avatar r~~‭ · 2026-02-27T23:54:39Z (7 months ago)
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.