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?

Yd Ahhrk
  • 363
  • 3
  • 12
  • 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 https://unix.stackexchange.com/questions/83191/how-to-make-sudo-preserve-path (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
  • @StephenHarris I see. `/etc/environment` is precisely the reason why Ubuntu's sudo isn't giving me any problems. Its default `PATH` is quite thorough while Fedora's is empty. Thanks! – Yd Ahhrk Sep 20 '16 at 20:11
  • @derobert That's right; flagging. – Yd Ahhrk Sep 20 '16 at 20:15

1 Answers1

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.

mdpc
  • 6,736
  • 3
  • 32
  • 46
  • 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