Login shell option

[mintty]

People keep requesting wsltty control over login shell behaviour.
Could wslbridge add an option, like - or -l?
Which would be propagated to argv[0] being stripped to its basename and prepended with a -.
This relates to previous discussions in #9, mintty/wsltty#56, (#14, mintty/wsltty#37).

[rprichard]

I think wslbridge should follow ssh convention and, when a command isn't specified, add a - prefix to the basename of the user's default shell and use that for argv[0].

I suppose I can also add a wslbridge option that makes the - prefixing behavior explicit. -l works. It would have the neat effect that wslbridge -l bash and wslbridge bash -l will both start login shells, but the $0 will be different between them.

[mintty]

Oh, -l works already? I wasn't aware; I guess I can work with that, then, thanks.

[mintty]

Ah, no, not included yet. Support would be good. Could as well be triggered by supplying argv[0] like "-wslbridge" to wslbridge.exe itself. Or -l, or either of them.

[rprichard]

@mintty I have a version of this prototyped at https://github.com/rprichard/wslbridge/tree/login-mode. There are still some TODO comments, but it's mostly done. The dash-prefixed behavior can be explicitly requested by passing -l to wslbridge or by using a '-' prefix on wslbridge's argv[0]. By default, wslbridge uses the user's configured WSL shell and invokes it with a '-' prefix.

[mintty]

Sounds great! But what if you want to invoke the default distribution without login mode? I'd rather decouple the two issues. Will take a look.

[rprichard]

I'd be OK with having multiple options: -l / --login / --no-login

I'd expect wslbridge to default to starting a login shell, because ssh also does that (as does starting WSL bash.exe or wsl.exe). In principle, there's no WSL environment set up yet, so we usually want to source the user's profile before starting anything interactive.

[mintty]

Bit confused I am; if you want to make login mode the default, you wouldn't need a -l option or argv[0] detection, right?

[BrianInglis]

... or we might want to mintty -h a -s24x80 /bin/env BASH_ENV=\$HOME/.bash_env /bin/bash "$@" for non-interactive commands: I use shell scripts to checkout things in cygwin-32, cygwin-64, and wsl environments from the others, similar to scripts to run local commands in (effectively popup) terminal windows, and ssh scripts for remote systems.

[mintty]

@rprichard, I'm trying to build wsltty with the latest commit from branch login-shell, but it doesn't work as you also modified the backend. Can you make a release please?

[rprichard]

Yes, I'll make a release when I have time. Probably before the end of the year.

[mintty]

Or let's check this first:
I'm frequently getting
wslbridge error: connection broken
with wslbridge-frontend from the login-shell branch. Could be that it happens only because the backend does not match (so I haven't submitted a separate issue for now).
It happens during sudo apt install gcc, which fails, by the way, so I cannot build the backend myself...

[rprichard]

IIRC, this commit changes the protocol the frontend and backend use, so they both need to be recompiled.

I don't see why you can't recompile the backend. You could run sudo apt install gcc without using wslbridge? If apt is broken, then nuke your WSL environment and start over?

[mintty]

I could build wslbridge-backend in OpenSUSE, and it works well.
Also, it starts a login shell; however: it always does so, even if not requested via arg0.
Can we please make it optional?

[rprichard]

Also, it starts a login shell; however: it always does so, even if not requested via arg0.
Can we please make it optional?

I guess? I'm confused by the request, though, because I'm just following the existing Unix (and WSL) conventions.

[mintty]

My proposal is to behave like typical shells:

• Start a login shell if wslbridge is invoked either with argv0=-wslbridge (or actually, -anything) or has an explicit -l (or --login) argument.
• Do not start a login shell if wslbridge is invoked with argv0=/bin/wslbridge (or actually, without -) and has no explicit -l (or --login) argument.

[mintty]

What I see in your -h output and code, this seems to be the current approach, I didn't see a bug at least.
Testing from cmd.exe once more, it seems that MS have changed their policy to start a login shell by default. I tried bash -h and this started a non-login shell; weird.
This means wslbridge might have to add a dedicated parameter to not start a login shell, or we might conclude that it's not worth the effort.

[rprichard]

Fixed by 34ec0e4