ek@Cord:~$ command -v git-lsx
/home/ek/bin/git-lsx
ek@Cord:~$ git-lsx
fatal: not a git repository (or any of the parent directories): .git
ek@Cord:~$ sudo git-lsx
sudo: git-lsx: command not found
ek@Cord:~$ sudo -E git-lsx
sudo: git-lsx: command not found
ek@Cord:~$ sudo --preserve-env git-lsx  # same as sudo -E
sudo: git-lsx: command not found
ek@Cord:~$ sudo --preserve-env=PATH git-lsx  # stronger, but insufficient
sudo: git-lsx: command not found
ek@Cord:~$ sudo PATH="$PATH" git-lsx  # similarly insufficient

ek@Cord:~$ SUDO_USER='Owls rule!' sudo -E printenv SUDO_USER
ek
ek@Cord:~$ SUDO_USER='Owls rule!' sudo --preserve-env=SUDO_USER printenv SUDO_USER
Owls rule!

But --preserve-env=list does work to preserve variables that sudo sets even with -E. This appears broadly to be the case, and not to be specific to the semi-undocumented case of PATH. For example:

ubuntu@bionic:~$ printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
ubuntu@bionic:~$ sudo printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
ubuntu@bionic:~$ sudo -E printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
ubuntu@bionic:~$ sudo --preserve-env printenv PATH  # same as -E
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
ubuntu@bionic:~$ sudo --preserve-env=PATH printenv PATH

Should the answer be changed so it does not imply that sudo -E command looks up command using the $PATH that sudo inherits from the caller?

but, sudo -E command does not preserve PATH

The parsing of sed -i 1s/^/#/ is done by sudo -e/sudoedit or visudo (or something they call). It's independent of the shell that's used to run them with an environment variable set to that value, and it doesn't observe the same rules as the shell does.

sudo -e/sudoedit and visudo are not using the value of EDITOR, VISUAL, or SUDO_EDITOR as a command name. If they were, this wouldn't work at all; there is no command called sed -i 1s/^/#/. What allows that to work is that the value is being used as a command name followed by zero or more arguments to the command. The filename of the temporary file is passed as a final argument after that.

On my 16.04 and 18.04 systems, the manpage for visudo doesn't mention SUDO_EDITOR. It appears that, until recently, SUDO_EDITOR has been used only by sudo -e and sudoedit, not by visudo. I also just got the same behavior you saw--where my default interactive editor opens--when I tried the command on a 16.04 system.

I assume the command just doesn't work on 18.04, having to do with what works as an editor for sudo -e, sudoedit, and visudo in what versions of sudo.

ubuntu@eoan:~$ sudo SUDO_EDITOR='sed -i 1s/^/?/' visudo -f /etc/sudoers.d/keep-home
>>> /etc/sudoers.d/keep-home: syntax error near line 1 <<<
What now? q
Options are:
  (e)dit sudoers file again
  e(x)it without saving changes to sudoers file
  (Q)uit and save changes to sudoers file (DANGER!)

What now? x

How does sudo -e / sudoedit / visudo split the value of SUDO_EDITOR (or VISUAL, or EDITOR) into arguments? Does it just match [[:blank:]]+ as a delimiter?

At first I thought this might be due to [updated configuration files][2]. I can make it so `sudo` behaves this way on earlier releases--always resetting `$HOME` unless overridden by `--preserve-env` or `-E`--by editing `/etc/sudoers` (`sudo visudo`) or a file in `/etc/sudoers.d` (e.g. `sudo visudo -f /etc/sudoers.d/always_set_home`) to add:

    Defaults        always_set_home

But I checked, and `always_set_home` does not appear in any `Defaults` line in the 19.10 `sudoers` file.

I was surprised to find that the upgrade from Artful to Bionic, which didn't require e to do anything special -- the Software Updater offered it and was able to start it -- actually had errors. It performed the upgrade, but I had to run sudo apt install --fix-broken to fix problems (it ran dpkg --configure -a itself to attempt to fix them, but apparently did not proceed to run apt-get install --fix-broken or equivalent) with a couple packages.

So, do you think sudo -E not using the user's PATH is the intended behaviour, only seemingly not well documented and somewhat counterintuitive?

Yeah, that's also basically why I didn't try to add anything to (or remove anything from) that part. But you link to a post on Unix & Linux. That's to support the claim that sudo -E won't do what the OP wants on Ubuntu, right?

I had observed that before; I always figured it was the intended behavior of sudo -E on any system where sudo is configured to use secure_path. Is that not so?

ek@Io:~$ FOO=bar sudo -E printenv FOO
bar
ek@Io:~$ echo "$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
ek@Io:~$ PATH="$PATH" sudo -E printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

So is it specifically for PATH that sudo -E doesn't work on Ubuntu? On my 16.04 system:

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

$ sudo find /media/michael/ -type d -name '[Ss]pielearchiv' -exec du -h --max-depth=1 {} \; | grep -E '^\S+G'

ek@Io:~$ sudo lsof | grep -E '^COMMAND|417702[678]'
[sudo] password for ek:
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
COMMAND     PID   TID       USER   FD      TYPE             DEVICE    SIZE/OFF       NODE NAME
sshd      29779               as   10w     FIFO               0,10         0t0    4177026 pipe
sshd      29779               as   11r     FIFO               0,10         0t0    4177027 pipe
sshd      29779               as   13r     FIFO               0,10         0t0    4177028 pipe