What happens to the environment when you run “su -c”?

Question

What happens to the environment when you run "su -c"?

The reason I ask, is this mysterious behavior:

bash$ which firefox
/usr/local/bin/firefox
bash$ su - user -c "echo $PATH"
bin:/usr/bin:/sbin:/usr/sbin:/opt/java/bin:/usr/local/bin:... 
bash$ su - user -c "firefox ..."
-bash: firefox: command not found

Any ideas?

Answer 1

What you are seeing is the fact that $PATH is expanded in the first users shell during argument processing, before the su(1) command runs, so it looks like it always does. If you use hard quotes ('echo $PATH') you should see something different, or just do \$.

This will preserve the $PATH syntax until after the su(1) command runs. While it normally doesn't fiddle with the environment, it does start a new shell, and so you should check for PATH= lines in the various shell startup scripts.

Your su(1) has a -c option, so you would seem to be on Linux. On a Mac or a BSD you would get a simplified PATH instead of the login PATH but you would still have the same "when did I expand PATH?" issue.

Answer 2

When su - or su -l is used, it emulates a login session, which involves resetting the environment to a clean state.

On Arch Linux, su - uses the hardcoded string /usr/ucb:/bin:/usr/bin:/etc as the new $PATH. On other systems, it might read ENV_SUPATH from /etc/login.defs, or rely on PAM to set up environment.

su ... "echo $PATH" lies, because the $PATH part is expanded by your current shell, way before su is launched. Use su ... 'echo $PATH' instead (note the single quotes), or su - -c env (prints the complete environment).