Add "Run as login shell" option for Bash.

[dnt294]

I've installed and managed to make rvm, ruby and rails work. But after close Bash and open another instance, I can't get ruby or rails worked. I get this error when try to call ruby:

Workaround here is to add bash --login every time open a new Bash, while Ubuntu's terminal has an toggle "run as login shell" in its option.

[xob]

Another option is to add --login to the shotcut used to launch bash.

[benhillis]

Closing this out because there is a way to run as a login shell (via passing -l or --login to bash.exe)

[aseering]

@benhillis -- The issue as I see it here is that the shortcut to open a shell on Windows does not provide a shell whose environment is comparable to the shortcut to open a shell on Ubuntu. That appears to meet your own criteria for a bug -- it's a point of incompatibility that has resulted in a number of tickets filed by users who don't understand their shell's behavior. It's true that there's a workaround, but the workaround isn't a fix...

I'd really like to see this ticket either re-opened, or closed as a dupe with a reference to some other ticket that's tracking the work.

[benhillis]

@aseering - agreed, reopening.

[aseering]

ping -- any updates on this?

[benhillis]

@aseering I'll check with the team on their thoughts about adding --login to the default shortcut.

[aseering]

Thanks @benhillis ! For what it's worth, I understand the argument that this is kind of a hack as compared to re-thinking init, or even /bin/login. My question is, as WSL picks up users, will it be easier to transition people from a default minimal shell to a default proper login shell, or from a default --login shell to a proper login shell?

[aseering]

ping -- someone else hit this :-)

[benhillis]

Unfortunately I couldn't get quorum to add this for Creators Update. User's that want a login shell will have to manually modify their shortcut or use bash.exe -l

[aseering]

Thanks @benhillis for the update. This underlying issue has been around since before freeze for the Anniversary Update (though this particular ticket was filed right after it shipped). Given that this is the sort of change that only becomes harder to make over time, and given that it has missed two releases already, can we take this to mean that you don't plan to implement this change?

[benhillis]

I would say that since there is such a simple workaround the team feels this is a documentation issue rather than a code defect. I've reached out to @jackchammons to make sure we have a blurb about running bash as a login shell.

[aseering]

Ok -- I mean, there are lots of things with simple workarounds that y'all have chosen to fix. You appear to be confirming that:

• this one is not likely to be fixed, and
• the objective is not to match Ubuntus' behavior here.

Please let me know if that's inaccurate.

[benhillis]

We have not yet made that determination. I think the greater problem is that to truly match Ubuntu's behavior we should switch over to using /bin/login. That would solve this as well as a number of other issues but it does come with some interesting baggage which is why we have not yet done it.

[aseering]

Your point about /bin/login is a good one. However, what WSL should really do if the objective is to maximize compatibility is to have Ubuntu's /bin/init (or an appropriate one of its many children) fork a login shell. That would solve a whole lot of problems, including this one and including many that /bin/login would not solve. It would also drag quite a large pile of baggage along with it :-)

/bin/login is not a complete solution, but it would be a substantial improvement. /bin/bash --login is also not a complete solution; it would also be an improvement, and a step towards /bin/login. Either way, I hope y'all choose to do something incremental -- it would be wonderful to have all the various system-environment-related details working properly, but I for one will get grumpy if I have to wait until then just to have stock WSL run my dotfiles :-)

Anyway -- thanks for bringing this up with the WSL team, and for the feedback about y'all's thought process. I appreciate knowing what's going on. Also, thanks for all the fixes that you have gotten in :-)

[shawnz]

I don't think it is sufficient to add -l to the default shortcut, because I think most users still expect their .profile to be applied even if they run 'bash' from the command line rather than clicking on the shortcut. There is also the issue of 'bash -c xyz' not applying the .profile (see #1404), which is the correct behaviour on Linux, but this makes sense on Linux because the .profile would have already been applied before the user ever has a chance to run 'bash -c'. The /bin/login solution fixes both these issues.

Maybe an alternative solution would be to allow the passing of specific environment variables from Windows into WSL (see #219), thus eliminating the need for .profile? If this were possible, commands which we would normally put in .profile could be run at Windows logon instead. However, this would require additional configuration to fix issues such as the OP's, and it would not be ideal for people who use the same dotfiles on all machines.

[rlabrecque]

--login is the fist step for sure but making it with /bin/login would definitely be nice.

I wouldn't like to see WSL not conforming to .profile. But it would be neat to see the windows environment variables injected in as a completely separate [optional-but-defaults-to-enabled] feature. (Probably with Win>Linux path fixup i.e. C:\ -> /mnt/c/). Just like the Path is. Hell then I could even make my own path with PATH="$PATH:$Path" if I wanted. Maybe they could be injected with a prefix like $WIN_Path?

[benhillis]

As of build 16188 when running bash.exe without arguments (or with the ~ argument) bash will be launched as a login shell. The same is true for the new wsl.exe binary (with the exception that wsl launches your user's default shell as a login shell).

[rlabrecque]

Awesome! Thanks @benhillis. Looking forward to trying it out!

[shawnz]

Thank you so much for this change @benhillis! It really helps.

That said, the approach of only launching bash as a login shell if there are no parameters given causes several scenarios to remain unfixed (particularly #1404 which is concerningly now marked "bydesign"). Why not just always run bash as a login shell if it's launched from bash.exe? Are there still future changes planned with regard to this behaviour?

[mungojam]

Seems to me that this is fixed in Fall Creator's Update as expected

[thesmart]

On a new install of Windows w/ all updates applied, opening Ubuntu still does not source /etc/environment:

$ cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/var/rbenv/bin"
$ echo $PATH | grep rbenv
$

It appears that creating an executable bash script in /etc/profile.d/* will get loaded upon process restart. This doesn't seem to work with sudo.

[therealkenc]

This was marked fixedinsiderbuilds as of 16188 (message) implying 16299 FCU. New landing zone for /etc/environment behaviour is #1405.

[trallnag]

@thesmart, I think this is due to /bin/login not being used by WSL for logging in. /etc/environment is parsed by Linux-PAM and the default config depends on /bin/login.