NT path is not available in SSH

[poma]

I currently run a background ssh server (dropbear) at Windows startup and to use Bash I use Putty that connects to localhost. In my case NT Path variable is not imported in Ubuntu. Looks like currently Path is somehow hard-injected at wsl startup and is not very flexible.

Maybe better approach would be to somehow expose Windows variables (/proc, syscall, whatever) and then have a small user script that appends path to current environment at startup so that users can customize how and when it is appended?

[benhillis]

@poma - Good suggestion, an easy way for users to convert NT->LX and LX->NT paths has come up a few times. Your idea of a virtual file is an interesting idea.

[therealkenc]

Your idea of a virtual file is an interesting idea.

You could expose the registry entries in /proc, sure...

HKEY_CURRENT_USER\Environment
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

That would be interesting idea. [Heck, it would be "interesting" if the whole registry tree were a read/write filesystem under /proc or elsewhere. But I digress.]

But using the registry for WSL's definition of $PATH is kind of the wrong layer. Here is our current behavior:

C:\>set PATH=C:\foo
C:\>echo %PATH%
C:\foo
C:\>C:\Windows\System32\bash.exe
ken@DESKTOP-9BDQA3V:/mnt/c$ echo $PATH
/usr/local/sbin/:/usr/local/bin: ...blah blah.... /mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files/Microsoft SQL .....

"That ain't right". Nor is $PATH a special case here. You could make the same argument for $TERM (which came up recently), $DISPLAY, $HOMEPATH, etc. Or for that matter $INCLUDE, $WindowsSdkDir, $WindowsLibPath (ad nausium). That is, if one is making the case that you should be able to launch cl.exe using WSL introp. Which, at least on paper, we are, right? The $PATH to cl.exe doesn't even live in the registry, because, you can't have too many versions of the thing in your filesystem.

[therealkenc]

WSLENV was added in 17063.

[ketozhang]

I don't understand how the addition of WSLENV fix this problem.

Do I have to add some sort of injection of $env:path to WSLPATH=$env:path/u then add that to WSL $PATH later (which doesnt work)?

[DrVanScott]

From my point of view, WSLENV doesn't help here as WSLENV is itself not set if the shell is started via ssh. One could argue to define WSLENV in some shell startup files, but that would only work for (wsl->cmd) and not the other way round...

A WSL login shell shouldn't behave differently for

• direct invocation
• ssh login

e.g

echo $WSLENV

or

cmd.exe

should behave the same

[therealkenc]

I don't understand how the addition of WSLENV fix this problem.

You're right, actually. It doesn't. This issue went sideways on OP second paragraph "Maybe better approach would be to somehow expose Windows variables". The approach taken was $WSLENV (for better or worse), and this submission went down with it.

The title and first paragraph of the OP, meanwhile, was about ssh/sshd behavior. Which is not a WSL topic at all, ref #4911.

[ketozhang]

The title and first paragraph of the OP, meanwhile, was about ssh/sshd behavior. Which is not a WSL topic at all, ref #4911.

Getting back to the topic of the title "NT path is not available in SSH", in #4911 the example was

> ssh user@host
$ /mnt/c/Windows/System32/cmd.exe /C echo test

We definitely can access to any command in NT using the full path of course. The behavior I'd expect would be to use all environment as if $env:path was injected as it is when using wsl hence being able to shorten the command to just cmd /C echo test. However, this isn't true as you said SSH/SSHD doesn't do this.

Do you have any suggestion on repeating this injection. Maybe it should be a command in~/.profile, ~/.bashrc, ... for those that want the behavior.

[therealkenc]

The behavior I'd expect would be to use all environment as if $env:path was injected as it is when using wsl

That would be an unusual thing to expect, since the ssh.exe application has never heard of WSL, and the sshd app on the Linux side doesn't even know it is running in WSL.

WSL, for its part, knows nothing of either ssh or sshd.

Do you have any suggestion on repeating this injection

Yes, in the first reply of #4911 which is still open (or at least, not quite dead yet).

Contrast this closed issue, which was a request to quoth: "somehow expose Windows variables (/proc, syscall, whatever)". Which for better or for worse, addressed with $WSLENV but does not help the OP's use case.