0

Assume the following script:

$ cat test.sh
#!/bin/bash
echo $PATH

This happens:

$ echo $PATH
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/<user>/.local/bin:/home/<user>/bin
$ sudo ip netns exec blue echo $PATH
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/<user>/.local/bin:/home/<user>/bin
$ ./test.sh
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/<user>/.local/bin:/home/<user>/bin
$ sudo ip netns exec blue ./test.sh
/sbin:/bin:/usr/sbin:/usr/bin

Why. It's breaking my scripts ecosystem because it means they cannot see many of my binaries.

Out of the two distributions I've tested this in, Fedora 24 is the only one that does it. Ubuntu 14.04 echoes all $PATHs the same as I expect.

I tried adding to the script

$ sudo ip netns exec blue PATH=$PATH

But it errors out, presumably because PATH=etcetc is not really a command.

What is the correct way to do it?

7
  • 3
    Are you sure it's not sudo changing the path? – derobert Sep 20 '16 at 17:41
  • @derobert Yes, that seems to be the case. sudo ./test.sh prints the short version so the problem has nothing to do with network namespaces. I'm still not sure how to fix it, though. ip netns needs privileges... – Yd Ahhrk Sep 20 '16 at 17:57
  • I guess I should completely revamp the question. Hope I find the answer as I do so. – Yd Ahhrk Sep 20 '16 at 17:59
  • 2
    @YdAhhrk man sudoers tells you all about PATH resets. – Stephen Harris Sep 20 '16 at 18:31
  • 1
    @YdAhhrk before you revamp your question... is your answer found at unix.stackexchange.com/questions/83191/… (or any of the others found as the top few results when you plop sudo path in the search box)? If so, we can close this as a duplicate, and your problem is solved. – derobert Sep 20 '16 at 18:39
0

You can always do two things: Use the fully qualified name of the command, thus there is no doubt. In any of my scripting, I specifically set the PATH variable inside the script to avoid problems with external modifications to the environment (i.e. be independent of the environment). This seems to be a good general practice anyway.

3
  • Okay, but if the user chooses to install the programs elsewhere, wouldn't overriding PATH practically ensure your scripts won't work? – Yd Ahhrk Sep 20 '16 at 18:04
  • I also don't see any guarantees that the programs will (by default) be installed in the same directory in every environment. Distros tend to be rather chaotic in this kind of regard. But maybe this is just my own ignorance. – Yd Ahhrk Sep 20 '16 at 18:16
  • Those are the reasons why I currently feel that trusting a given and standard environment configuration (ie. PATH) is the most sensible solution. – Yd Ahhrk Sep 20 '16 at 18:20

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