configurable launcher

[mintty]

With MS-Store-based WSL, the launcher is not bash.exe anymore.
It would be useful to add an option to set the desired launcher, e.g. (e.g. -l %LOCALAPPDATA%/Microsoft/WindowsApps/ubuntu.exe).

Another open issue is to find out which incarnations of WSL exist on the system (apparently now multiple installations can coexist, and other distributions than Ubuntu are under preparation).
See wsltty/issues#52.

[mintty]

@rprichard, do you have an idea how to explicitly launch the distros in either the current directory or the home directory, without having to tweak the WSL default distro? See the discussion starting from microsoft/WSL#2348 (comment).

[rprichard]

I started on a --wsl-launcher option in the wsl-launcher branch. It doesn't work because bash.exe and the new Store ubuntu.exe parse their command lines differently.

e.g.:

C:\Data>bash.exe -c ls /
LogFiles

C:\Data>bash.exe -c "ls /"
bin  boot  dev  etc  home  init  lib  lib64  media  mnt  opt  proc  root  run  sbin  snap  srv  sys  tmp  usr  var

C:\Data>bash.exe -c 'ls /'
bin  boot  dev  etc  home  init  lib  lib64  media  mnt  opt  proc  root  run  sbin  snap  srv  sys  tmp  usr  var

C:\Data>ubuntu.exe -c ls /
bin  boot  dev  etc  home  init  lib  lib64  media  mnt  opt  proc  root  run  sbin  snap  srv  sys  tmp  usr  var

C:\Data>ubuntu.exe -c "ls /"
bin  boot  dev  etc  home  init  lib  lib64  media  mnt  opt  proc  root  run  sbin  snap  srv  sys  tmp  usr  var

C:\Data>ubuntu.exe -c 'ls /'
/bin/bash: ls /: No such file or directory

[rprichard]

Should wslbridge search the PATH for the given program, e.g so that --wsl-launcher ubuntu works?

I wasn't sure it made sense to allocate -l as the WSL launcher option, but -l ubuntu is pretty convenient, so maybe it does.

bash.exe --help shows the help page for WSL's GNU bash, whereas ubuntu.exe --help is an error. ubuntu.exe /? shows the help page for ubuntu.exe, and it doesn't mention a -c option. I'm guessing that ubuntu.exe -c ... does the same thing as ubuntu.exe run ....

[mintty]

I agree with your hidden statement that this is all very chaotic and undocumented.

To find the launcher, I guess it's sufficient to look in %LOCALAPPDATA%\Microsoft\WindowsApps (that's also included in the PATH). However, what that means for other users, given that the "app" itself is installed in %PROGRAMFILES%\WindowsApps, I do not know. Maybe you can look up there as well (although the folder is not readable for normal users).

About parameter handling, our main issue is the question how to set the start directory. I would happily leave all other questions of parameter usage to users who want to launch WSL apps directly.

[mintty]

Please check microsoft/WSL#2348 (comment);
while this syntax is one of the gruesome Microsoft cryptics, if it works, that should be fine for us.
I can provide those cryptics in the shortcuts and .bat scripts I generate, or you could optionally look them up in the registry by the distro name.

[rprichard]

Maybe I should add a --distro-guid option, and if that option is specified, wslbridge should run wsl.exe instead of bash.exe. With that design, wslbridge would understand that wsl.exe and bash.exe represent command lines differently and do the correct escaping for each.

I need to study what that escaping is. I wonder if the differences were intentional, or will the next WSL distro cause problems again?

An alternative is to have the wslbridge frontend thoroughly escape shell control characters (spaces, quotes, slashes, etc) and make little-to-no assumptions about how bash.exe and wsl.exe handle command lines.

[mintty]

wsl.exe instead of bash.exe

I've just tried wsl {5131dac2-195d-4720-bdf5-846c2bf311b5} etc and it works for either wsl or bash alike. Both also accept ~ and work as useful.

So a possible wslbridge option (short preferred) could be like
-l {5131dac2-195d-4720-bdf5-846c2bf311b5} (l for launch), or if you like, -l Ubuntu and you could enumerate HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss to match DistributionName=Ubuntu and find the key (as a convenience for others perhaps; the new wsltty installer does the enumeration already and would not need that). The two ways could simply be distinguished by the starting '{'.

I do not see what problem with escaping there is, it doesn't seem to be important for wsltty.

[mintty]

it works for either wsl or bash alike

However, bash accepts a -c option while wsl does not.
Also the order of options used is important; first {...}, then ~, then -c.

[rprichard]

I pushed a commit to the wsl-launcher branch that replaces --wsl-launcher with a --distro-guid argument. Let me know if it works for you.

I think I'm open to having wslbridge scan HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss for a list of distributions. Maybe it'd allow something like wslbridge -d Ubuntu -t bash --login.

Conceivably, there could be single -d / --distro argument that allows either a distro name or a GUID.

The current GUID parsing is flexible -- see the canonicalGuid function. Letters can be lower or upper case, and it can be surrounded by braces or not. I assume mintty would simply pass the value from the registry.

I wonder if two distributions can have the same name (but different GUIDs).

[rprichard]

It looks like wsl.exe doesn't do the Press any key to continue... prompt for the Cannot launch because another instance is running elevated. error. Maybe wslbridge's press-return functionality could be disabled for wsl.exe.

[rprichard]

@mintty Oh, I didn't see your comments before I posted. Maybe the fix is much simpler, then. wslbridge continues using bash.exe unconditionally, but adds a GUID as the first argument if it's specified.

[rprichard]

Ok, I pushed the simpler --distro-guid implementation to the distro-guid branch. I don't think I'm going to work on a convenient argument option for now.

[mintty]

Thanks a lot. Just uploaded wsltty updates to support the new WSL distribution model.
No release yet (referring to mintty-master and wslbridge/branch/commit).

[mintty]

Thank you again. I made a release meanwhile, referring to
wslbridge-cb22e3f6f989cefe5b6599d3c04422ded74db664 which is within the distro-guid branch.
I'd close this issue once it's merged to the main branch and released :)

[rprichard]

The --distro-guid option is now released in wslbridge 0.2.4.

[mintty]

Great, thanks!