0

This question https://superuser.com/questions/319043/runing-a-command-without-inheriting-parents-environment suggests that we can run a command without inheriting parent's environment by

$ sudo -u "`whoami`" $COMMAND

Are there ways to do it without using sudo? Since while sudo is very popular, it hasn't reach the portable status (or in POSIX) yet.

I have tried env -i $COMMAND, but it is no good, since it removes all the environment variables. What I want is to run the command in the default environment.

  • 1
    what are you defining as the default environment? – thrig Sep 7 '18 at 16:01
  • @thrig Perhaps the base environment you get when you execute a command with sudo... – Alex Vong Sep 7 '18 at 16:06
  • @thrig Or the environment you get when you start a new terminal, assuming you do not change your ~/.bashrc or ~/.profile. – Alex Vong Sep 7 '18 at 16:09
  • or a "login" environment? – Jeff Schaller Sep 7 '18 at 16:10
  • @JeffSchaller Yes, I think so. – Alex Vong Sep 7 '18 at 16:17
2

login(1) traditionally sets a limited set of environment variables at, well, login time. Like su login will typically ask for a password even if one logins as oneself so that here is probably not ideal. Unix systems may have additional or different complications, e.g. if there is PAM pam_env(8) could add or remove environment variables from what was set by login. A copy of what login(1) does could thus create a different environment variable set than an actual login through PAM sets.

Then there are terminals and shells; terminals may or may not launch the subsequent process as a "login" shell. Shells may read different files when flagged as login and may end up with different env variables for login vs. non-login instances. There is existing literature on this topic.

So based on the unix, the login process, local system configuration, what shell the user uses, and local configuration for that shell there may be different environment variables set "by default."

You may be able to get a suitable list of environment variables with a login shell instance:

% export CANARY=tweet
% env -i bash -l -c 'env | grep CANARY'
/Users/jhqdoe/.profile: line 6: set: markdirs: invalid option name
% 

this does clear environment variables from the parent process (env | grep CANARY would be where your $COMMAND goes). .profile here is actually for mksh, not bash. However, the above may not set necessary variables that the login workflow sets as it does not go through that code. These might be inspected to see what they are with a new login and then to run:

$ env > def
$ env -i bash -l -c 'env > new'

And then to compare the def and new files to see how they differ (possibly involving the sort and diff commands), then possibly updating the env command to set things that are missed before then doing the login shell.

Another idea is to snapshot the environment and use that as the default.

  • I didn't know login also set environment variables. I always thought it is the shell which does that. Thanks for pointing me to that man page. So it seems using sudo is still the easiest way for now. – Alex Vong Sep 8 '18 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.