Obviate typing extension for Windows binaries is not working anymore in WSL2

[kiennq]

Please fill out the below information:

• Your Windows build number: Microsoft Windows [Version 10.0.18917.1000]

• What you're doing and what's happening:

1. Add command_not_found_handler to .zshrc as follow

# Obviate typing extension for Windows binaries
command_not_found_handler() {
  if command -v "$1.exe" >/dev/null; then
    eval "$1.exe ${@:2}"
    return $?
  elif cmd.exe /c "(where $1 || (help $1 |findstr /V Try)) >nul 2>nul && ($* || exit 0)"; then
    return $?
  else
    [[ -x /usr/lib/command-not-found ]] || return 1
    /usr/lib/command-not-found --no-failure-msg -- ${1+"$1"} && :
  fi
}

2. Reload zsh and try to type notepad

• What's wrong / what should be happening instead:
  Expected: notepad.exe is launched in Windows
  Actual: zsh: operation not permitted: notepad
  This is working fine in WSL1

[therealkenc]

I can't repro this (notepad launches with the zsh magicscript), and I can't repro the "operation not permitted" a little below you #4162 either. Which is to say at the very least, coincidental. At the moment I can't guess the variable with the steps given in either issue.

[kiennq]

I have repro here.
Hmm, do you need other information?

[therealkenc]

The steps prior to the point you typed nvim ~/.zshrc above that is causing the fail.

No not seriously. But the above is, most unfortunately, not the repro. It's a screencap demonstrating it isn't working for you; a data point that was not in question.

[kiennq]

That why I'm asking if there is additional information I can provide?
That is the freshly launch WSL2 instance I used to take the screencap. With only the default shell set to zsh and the .zshrc content is like what's in screencap.
In Windows I can probably take a TTD trace for investigation, but in the land of Linux I have no idea which information I can provide to make this to be investigated easier.

[therealkenc]

That why I'm asking if there is additional information I can provide?

You can try doing:

$ strace -f -o zsh.strace /bin/zsh
[type notepad, then enter, then ctrl-d to exit]

Then link a gist containing the contents of zsh.strace. It's a longshot the trace log will tell us much. This is mine:

22    execve("/bin/zsh", ["/bin/zsh"], 0x7fff9e7ae2e8 /* 20 vars */) = 0
22    brk(NULL)                         = 0x55a0a3157000
22    access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
[lots of blah blah... Then here it is going through my path elements looking for notepad]
24    execve("/usr/local/sbin/notepad", ["notepad"], 0x7ffca6708378 /* 20 vars */) = -1 ENOENT (No such file or directory)
24    openat(AT_FDCWD, "/usr/local/sbin/notepad", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
24    execve("/usr/local/bin/notepad", ["notepad"], 0x7ffca6708378 /* 20 vars */) = -1 ENOENT (No such file or directory)
24    openat(AT_FDCWD, "/usr/local/bin/notepad", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
24    rt_sigprocmask(SIG_UNBLOCK, [WINCH], [], 8) = 0
[... etc etc lots of those. Doesn't find anything. Then prep the null redirect]
24    openat(AT_FDCWD, "/dev/null", O_WRONLY|O_CREAT|O_NOCTTY|O_TRUNC, 0666) = 3
[... finds the new string notepad.exe in my WINDOWS path]
24    access("/mnt/c/WINDOWS/system32/notepad.exe", X_OK) = 0
24    stat("/mnt/c/WINDOWS/system32/notepad.exe", {st_mode=S_IFREG|0555, st_size=200704, ...}) = 0
24    write(1, "/mnt/c/WINDOWS/system32/notepad."..., 36) = 36
[... lots of prep for the execve, and then finally....]
25    execve("/mnt/c/WINDOWS/system32/notepad.exe", ["notepad.exe"], 0x7ffca6708378 /* 20 vars */ <unfinished ...>
24    <... rt_sigprocmask resumed> [CHLD], 8) = 0
24    rt_sigsuspend([INT], 8 <unfinished ...>
25    <... execve resumed> )            = 0

You might want to wait for a couple more me2s. We're taking as a given that typing the full notepad.exe actually launches Notepad, correct.

[kiennq]

Thanks, I've attached gist here.
Interestingly, in my strace, it seems that the null redirect is not called?

[therealkenc]

Hah! Thanks for doing the follow up. You've got:

53    execve("/mnt/c/ProgramData/scoop/apps/golang/current/bin/notepad", ["notepad"], 0x7ffd8978f168 /* 23 vars */) = -1 EPERM (Operation not permitted)
53    rt_sigprocmask(SIG_UNBLOCK, [WINCH], [], 8) = 0

This is variation #3886 #3833. The reproduction steps you missed in your motion GIF was installing Windows Scoop (???) + Golang (which would be a longer motion GIF).

This is also going to be same fail #4162 and I bet a nickle #4127. Of course, the errant $PATH component isn't going to be Golang for everyone. The work-around is to purge whatever errant components in your $PATH per #3886 (message).

[kiennq]

Thank you, since the errant paths are all windows's symlink. It's more likely related to #4104 to me.
Thanks for your help again.

[therealkenc]

It's more likely related to #4104 to me.

Sort of, yes. The #4104 fail is triggering a variant #3886 fail, in your case. But very much appreciate you sharing the detail that it was symlinks, because that's a very good data point.

Calling this a dupe (pick the one you like best). Work-around remains laundering your $PATH.

[kiennq]

Just in case if anyone wonder how I clean my $PATH upon zsh launches.
Here is the script to put into .zshrc

# Filter bad path
function () {
  local OPATH="$PATH"
  PATH=""
  while read -d ':' p; do
    if [ -x $p ]; then PATH=$PATH:$p; fi
  done <<< "$OPATH:"
}