Linux Environment Variables: env, export, and /etc/environment

Articles & guides
1
Read the full article: Linux Environment Variables: env, export, and /etc/environment

A practical guide to Linux environment variables: how to set, export, persist, and debug them correctly across shell sessions, user accounts, system-wide configs, and systemd services. continue reading.
3 Likes
2

Nice write up,very informative and I learned a lot. :+1:

1 Like
4

That is a beautiful introduction to environment variables :+1:

There is only one thing that, in my opinion, could have a bit more thought and attention because it is often used without thinking.

I see this: #!/usr/bin/env python3

which i often agree with

(on a lot of systems a ‘bring your own version’ python is often needed since every python version is incompatible with the previous one and probably also with the system provided one)

I also see this: #!/usr/bin/env bash

which in my opinion is definitely not really a good idea.

Someone on stackexchange formulated perfectly why:

The advantage of #!/usr/bin/env python is that it will use whatever python executable appears first in the user’s $PATH.

The disadvantage of #!/usr/bin/env python is that it will use whatever python executable appears first in the user’s $PATH.

:joy:

That means that the script could behave differently depending on who runs it. For one user, it might use the /usr/bin/python that was installed with the OS. For another, it might use an experimental /home/phred/bin/python that doesn’t quite work correctly.

And if python is only installed in /usr/local/bin, a user who doesn’t have /usr/local/bin in $PATH won’t even be able to run the script. (That’s probably not too likely on modern systems, but it could easily happen for a more obscure interpreter.)

By specifying #!/usr/bin/python you specify exactly which interpreter will be used to run the script on a particular system.

Another potential problem is that on many systems, the #!/usr/bin/env trick doesn’t let you pass arguments to the intrepreter (other than the name of the script, which is passed implicitly).

Keith Thompson, Jan 21, 2012 , https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my

And also this:

  • #!/usr/bin/bash: Safer in high-security contexts. Since the path is fixed, there’s no risk of an attacker hijacking PATH to trick the script into running a malicious bash executable.
  • #!/usr/bin/env bash: Slightly riskier. If an attacker modifies PATH to include a directory with a malicious bash executable, env will run that instead of the legitimate one. This is a concern for scripts run with elevated privileges (e.g., sudo or setuid scripts).

What's the Difference Between `#!/usr/bin/env bash` and `#!/usr/bin/bash` in Bash Scripts? — linuxvox.com

The reasons above are pretty much the reasons why you’ll never find #!/usr/bin/env bash in any of my scripts.

4 Likes
5

Good points @tkn and fair pushback on the bash shebang. Using env makes sense for things like python or node, where the binary can live in different spots depending on the system or version manager. But bash is pretty much always at /bin/bash on any Linux system you’d run the script on, so you’re trading a real security concern for portability you don’t really need.

The PATH hijacking risk is the part most of us overlook. For anything running with sudo or in a shared environment, hardcoding the path is the safer call. Going to add a note to the article about when each makes sense instead of just defaulting to env. Appreciate you flagging it.

4 Likes