@Zanna Thanks! I noticed you omitted quoting in places where $PATH is expanded, even when citing muru's comments were quoting was used. Is this intentional, or an oversight?

(PATH can hold a value that contains spaces and whatnot, though I don't recommend people do that. I was just going to edit your post but I wanted to check since it seemed like it might've been an intentional choice.)

Also, are you sure the env command is ever needed for this? sudo supports VAR=val pairs, you just have to pass them as arguments to sudo before the command (rather than writing them before sudo in which case the shell applies them and sudo throws them out).

ek@Io:~$ sudo printenv foo
ek@Io:~$ sudo foo=bar printenv foo
bar
ek@Io:~$ sudo printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
ek@Io:~$ echo "$PATH"
/home/ek/.sdkman/candidates/kotlin/current/bin:/home/ek/perl5/perlbrew/bin:/home/ek/perl5/bin:/home/ek/.gem/ruby/2.3.0/bin:/home/ek/.local/bin:/home/ek/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
ek@Io:~$ sudo PATH="$PATH" printenv PATH
/home/ek/.sdkman/candidates/kotlin/current/bin:/home/ek/perl5/perlbrew/bin:/home/ek/perl5/bin:/home/ek/.gem/ruby/2…

@EliahKagan The only thing I can think of (at the moment) that would break that is set -k and it would also break the env way (and also I've never heard of anybody ever using set -k).

@EliahKagan I am sure!

@EliahKagan oh that was an oversight but I am afk

@Zanna Hmm, okay. You can tell me about it later if you have time, or maybe I'll figure out why it is sometimes needed.

@Zanna No problem, I'll edit it now. I won't mess with env though. :)

Edited.

@Zanna You are right! I was wrong to think env could be omitted here, as it certainly cannot. sudo env VAR=val command does indeed have a different effect from sudo VAR=val command and the former is needed in order for the assignment to affect the path lookup for command.

$ useless
useless: command not found
$ PATH="$PATH":~/junk useless
foo
$ sudo PATH="$PATH":~/junk useless
sudo: useless: command not found
$ sudo env PATH="$PATH":~/junk useless
foo

sudo VAR=val command passes VAR=val into the environment of command, assuming it manages to run command, but unlike with the corresponding construct in bash and with env, it doesn't look for command elsewhere even when VAR is PATH and val is a colon-delimited search path containing the name of a directory that contains an executable command.

When you get back please let me know if there anything you think I'm missing. If there is not can edit the post again to replace your guess as to why sudo PATH="$PATH" useless fails with a (don't worry, very short) version of the above.

* if there is anything

* then I can edit again

@EliahKagan thanks a lot! Bbl

No problem. You can let me know when you return if there's any reason not to edit the explanation of why env is needed.

I think I need to give attention to my answer about sudo and its recalcitrant environment, but I can't seem to contemplate that now! Thanks for your comments about that!

@Zanna I had said I would edit it again about that, but then I had not edited it when I went afk, and now I am back and perhaps I can edit it. To explain the situation might require material ot be moved around because it requires the non-working way to be compared to the working way, but the working way is late in the post, and the non-working way and the current guess as to why it doesn't work is early in the post.

I spent a lot of time trying to work out why sudo -E doesn't work, and trying to get it to work, even though I already knew it didn't work and its non-working was considered a bug. I should have paid more attention to why env is needed at all. Do you know where I can improve my understanding of that part? If so I will try to do that and edit it myself

@Zanna Well, does what I said there make sense?

Specifically, does it make sense that those examples without env all work, while those other examples without env work for the bash one but not for the sudo one?

sudo VAR=val command runs command with VAR=val, but that won't help to find the command - it doesn't modify sudo's environment which respects /etc/sudoers

(which in Ubuntu has env_reset and secure_path as Defaults)

unless the user has removed them...

Yeah. In contrast, both bash and env will use updated environment variables in resolving the path to the executable. (I don't know if this can be affected by setting any variables other than PATH itself, but it can certainly be affected by PATH.)

I don't think it's because of env_reset that sudo PATH="$PATH:/wherever" wherever-command doesn't work. I think that won't work even if env_reset is disabled, if /wherever is not in the PATH environment variable that sudo inherits.

oh I agree with that

But... I could be wrong about that.

sudo(8) says:

 Environment variables to be set for the command may also be passed on the
 command line in the form of VAR=value, e.g.
 LD_LIBRARY_PATH=/usr/local/pkg/lib.  Variables passed on the command line
 are subject to restrictions imposed by the security policy plugin.  The
 sudoers policy subjects variables passed on the command line to the same
 restrictions as normal environment variables with one important excep‐
 tion.  If the setenv option is set in sudoers, the command to be run has
 the SETENV tag set or the command matched is ALL, the user may set vari‐

But I don't think that's what's limiting it.

@EliahKagan but without env_reset and secure_path, I believe sudo would inherit the PATH. So if /wherever were in that path, it would be found

@EliahKagan no, I am pretty sure it isn't, because I tried a lot of things with setenv and SETENV, and none of them made any difference at all

@Zanna Right, but if /wherever were not in that path, but were added with VAR=val to the right of sudo but to the left of the command being run with sudo, then I believe the old (inherited) PATH would be used to find the command, and the new (changed) PATH would be passed into the command's own environment.

makes sense...

$ sudo printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
$ sudo PATH="$PATH" printenv PATH
/home/ek/perl5/perlbrew/bin:/home/ek/.sdkman/candidates/kotlin/current/bin:/home/ek/perl5/bin:/home/ek/.gem/ruby/2.3.0/bin:/home/ek/.local/bin:/home/ek/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

as you showed earlier... printenv got the message

Yeah. But printenv itself has to be in one of /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin.

luckily, we were able to find printenv to pass things to its environment :)

I don't really know why sudo gives this different, weaker meaning to VAR=value pairs than bash and env give it. But apparently it does. I also recall we have something about this on the site. So an edit could include a link to that, if it can be found. This whole thing rings a bell...

but without env_reset and secure_path we would be able to find it even if it were lurking in /home/ek/.local/bin, I think?

hmm anyway, time to sleep

@Zanna Yes.

@EliahKagan that would be good!

I looked though and I didn't find any posts about that.

Which does not mean, nor even suggest, that they're not there. I just don't know where they are.