Linux prompt does not appear on WSL

[seemann5]

Hello,

I am using the Windows Subsystem for Linux on Windows 10. In a nutshell, my problem is that the usual Linux prompt "username/path>" does not show up on any of Ubuntu or Debian, whether those are launched from the Windows command line (as shown below) or from the Windows applications.

• Some background history: for no obvious reason, my previous Windows User ended up corrupted. All my files were accessible but a new default session would show up after every reboot. I went through all tests and solutions suggested online, none worked, so I ended up creating a new Windows User (that's the "Vijeta" in the screenshot above).
  Everything was fixed until I realized that the WSL and my (previously working) Ubuntu application were not installed properly on this User. I thought it was due to the fact that I did not copy some files from AppData from my previous Windows user to the new one, so I tried fixing the problem manually to get all my previous settings, installed packages and so on... But it failed. I deleted all the newly copied files, but that's it, there was one folder that I copied and then deleted, everything should be back to normal.

• Then, I was getting something similar to what you can see on the screenshot. From then on, I've been installing and uninstalling Ubuntu and trying to install Debian instead. I tried to uninstall all Linux distributions I had, disable WSL, reboot, enable WSL, reboot, reinstall Ubuntu, but nothing changed.

-> Is there a way of directly fixing this issue (by modifying something in the .bashrc file, ...) ?
-> If not, is there a way of really uninstalling everything related to WSL and getting a fresh start?

[benhillis]

The distro-specific launcher binaries do not launch in your current Windows directory. If you want that behavior use wsl.exe.

[seemann5]

Hi, thanks for your reply! I tried what you said:

Did I do what you meant or am I missing something here?

[benhillis]

Sorry I misunderstood your question. What shell are you running?

echo $SHELL

ps -auxf

[seemann5]

I'm running bash apparently:

(The result is the same when I do it in wsl.exe or the applications Ubuntu or Debian)

[therealkenc]

Ben one way to reproduce this behaviour is start wsl.exe from a Windows Git Bash session (contrast Windows Git CMD session). You probably have it handy. Git Bash is of course just MSYS2 bash in a Windows Console mintty. At first it appears like WSL is just hung (which for a while I assumed was the case), but if you start entering commands (say ls) the session is live alright.

The reason there is no WSL bash prompt is $PS1 not set. Presumably because .bashrc doesn't get run, but I never really looked into it enough to say for sure. I just called wsl.exe from my Git Bash prompt at some point along the way and went, 'huh that's interesting'.

[Biswa96]

Did you try wsltty?

[therealkenc]

wsltty is fine. Although your question made me correct a point: Git Bash lives in mintty (sic) not Windows Console. Can't see how it is directly terminal emulation related though. The reason there is no prompt is because no $PS1. Or that's the hypothesis absent looking any deeper.

[seemann5]

The reason there is no WSL bash prompt is $PS1 not set. Presumably because .bashrc doesn't get run, but I never really looked into it enough to say for sure. I just called wsl.exe from my Git Bash prompt at some point along the way and went, 'huh that's interesting'.

Thanks for trying it out! So do you have any idea on how to have .bashrc getting run normally?

And if not, does anyone know a way of uninstalling everything related to WSL other than just uninstalling the Linux distribution apps & disable the WSL option in Windows parameters? (I'm pretty sure this can be fixed with a fresh installation since it used to work just fine on my other Windows user)

[benhillis]

Took a look at this and it looks like the issue to me is that git bash uses pipes for stdin / stdout / stderr when launching processes. After launching wsl.exe take a look at /proc/self/fd and you'll see file descriptors 0 1 and 2 are all pipes. I suspect this is causing /bin/bash to operate in "I'm not running in a console, better not print my prompt" mode.

[therealkenc]

"I'm not running in a console, better not print my prompt" mode

Yeah "there's your problem" alright. I think we're possibly just revisiting (poorly titled) #352. wsl.exe gets a pipe. But /bin/bash should get a tty. For example, from Git Bash (aka Mingw64) I can do:

there@DESKTOP-4UTIQSF MINGW64 ~ ssh.exe -p 2222 ken@localhost ls | findstr.exe somefile
somefile

and...

there@DESKTOP-4UTIQSF MINGW64 ~ echo hello | ssh.exe -p 2222 ken@localhost cat
hello

and just...

there@DESKTOP-4UTIQSF MINGW64 ~ ssh.exe -p 2222 ken@localhost
Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.4.0-17704-Microsoft x86_64)
[...blah blah]
Last login: Thu Jun 28 16:49:38 2018 from 127.0.0.1
ken@DESKTOP-4UTIQSF:~$ # working tty even though ssh.exe got the pipe from Ming64

That doesn't mean WSL's reimagination of sshd (WSL /init) needs to spew a welcome natch. But it should provide a tty, I think.

[Halkcyon]

I'd like to add to the conversation, I just enabled WSL today and out of the box, the ubuntu bash distribution is not printing the prompt. There is a default .bashrc, and $PS1 is defined.

echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
echo $SHELL
/bin/bash

[Biswa96]

@TheIncorrigible1 Which Windows version did you use? Does wsltty, wslbridge, or any SSH session (e.g. with putty or openssh in Windows) shows the prompt text?

[Halkcyon]

@Biswa96 I'm unfamiliar with any of those. Just using the Windows conhost, launching wsl/ubuntu/bash through cmd. All three executables do not show prompt text. I'm on the latest non-insiders Windows 10 build (1803).

[Berkmann18]

I'm facing the same issue where ubuntu started looking like it was hanging (no more prompt and capability to type commands in it) since yesterday.

I tried running ubuntu and bash from cmd, both lead to the same result.
When using Git Bash and running wsl.exe, allows me to type a command but there's no prompt nor do I see the result of those commands (e.g: echo $PS1 and ps).

Edit: Unchecking WSL in optionalfeatures.exe -> rebooting -> rechecking WSL -> rebooting seems to fix that.

[therealkenc]

looking like it was hanging

Yes the mode of failure is highly problematic. I thought it was hung too -- filed the problem under "scenario doesn't work" -- and moved on for the better part of a year before this issue was submitted in 2018.

The problem has gotten a bit more acute lately because WSL2 breaks wsltty. Wsltty arguably exists just to work-around this issue; from the standpoint that you could otherwise just type wsl.exe at a Git Bash prompt and get the same mintty goodness -- if that worked.

If the "MSYS2 uses pipes" problem can and should be fixed in MSYS2, then they could probably use some guidance as to how they could or should go about doing that. I haven't convinced myself that's exclusively the case though. If you do a Windows brand ssh.exe to WSL from inside Git Bash, you're golden. Which smells a lot like wsl.exe's wheelhouse. I could be convinced otherwise easy enough. But either way, this is a non-academic problem that hasn't been addressed in wsl.exe nor mintty.exe. Maybe it's both 🤷‍♂️.

[therealkenc]

Maybe it's both 🤷‍♂️.

I took a more serious dive on this over the weekend. It's both. Which is most unfortunate, because the WSL team can call this a mintty problem, and the mintty team can call it a wsl.exe problem. Both teams would be "not wrong" in coming to that conclusion.

On the mintty side of the fence, yes, as Ben points out, stdin/stdout/stderr are being presented to WSL as pipes, when they should presented as a tty. I put up a partial solution to that here. There are still some rough edges and I don't pretend wslterm is release-ready (it might not ever be), but it demonstrates one way this could be 'fixed'. Bizwa96 has an alternate approach here, using a socat-like intermediary to set up the pty. More expository in wsltty/wsltty#171 (message).

On the wsl.exe side of the fence, all of cmd.exe, powershell.exe, and (Windows 10 branded) ssh.exe work fine from a Git Bash (read: mintty) prompt. Only wsl.exe does not. You could (generously) call that a "limitation". In a more ideal world, wsl.exe would set up a pty if needed , like the Windows OpenSSH client MSYS2 ssh.exe client does. I'll take the liberty to tag this issue as feature request, with the only real alternative being to close it out tag by-design because "pipes".

[therealkenc]

[re strikeouts]

Dove more and the Windows branded OpenSSH client has the same behavior (no $PS1, looks hung) when run from Git Bash. Mass-confusion arose because Git Bash ships their own ssh.exe, and $PATH order matters. Ugh. This can in principle still be 'fixed' with (both) wsl.exe and /init changes, but after another 12 hours hard look, this is starting to look saner long term to address on the MSYS2 side for a number of technical reasons.

[Halkcyon]

I found the issue for me. My computer name is an emoji which breaks the bash prompt.

[allenabraham]

I was able to resolve my issue.
I had docker installed on my computer.
Somewhere down the line, it messed up my defaults of the wsl configuration and hence the expected behaviour of invoking the Linux Bash environment didn't happen when I typed wsl.exe.

I suggest that you run the below command and review the listing:
wslconfig /list /all

Look at my output below:
C:\Users\Allen>wslconfig /list /all
Windows Subsystem for Linux Distributions:
docker-desktop-data (Default)
docker-desktop
Ubuntu-20.04

The default should have been Ubuntu, so I used the following command to fix my issue:
C:\Users\Allen>wslconfig /setdefault Ubuntu-20.04

C:\Users\Allen>wslconfig /list /all
Windows Subsystem for Linux Distributions:
Ubuntu-20.04 (Default)
docker-desktop
docker-desktop-data

Hope it helps some of you if it is related to Docker messing up your setup.

[ghost]

I was able to resolve my issue.
I had docker installed on my computer.
Somewhere down the line, it messed up my defaults of the wsl configuration and hence the expected behaviour of invoking the Linux Bash environment didn't happen when I typed wsl.exe.

I suggest that you run the below command and review the listing:
wslconfig /list /all

Look at my output below:
C:\Users\Allen>wslconfig /list /all
Windows Subsystem for Linux Distributions:
docker-desktop-data (Default)
docker-desktop
Ubuntu-20.04

The default should have been Ubuntu, so I used the following command to fix my issue:
C:\Users\Allen>wslconfig /setdefault Ubuntu-20.04

C:\Users\Allen>wslconfig /list /all
Windows Subsystem for Linux Distributions:
Ubuntu-20.04 (Default)
docker-desktop
docker-desktop-data

Hope it helps some of you if it is related to Docker messing up your setup.

Yes, the exact same thing happened to me, I was on the WSL platform and everything was working well until I installed Docker.
Now the distros don't show up in wsl -l -v.

Obviously it's a new feature and there are so many bugs.

[therealkenc]

Wrapping this one: The OP as presented is in a largely unrecoverable need-repro state with no thumbs-up. Whatever was going on there I strongly suspect will be okay if WSL (1 or 2) is started with wsl.exe -d Ubuntu (or other distro) from Windows Terminal, contrast old-school ubuntu.exe. The drift to a discussion of git bash seems to be addressed externally (or some combination of external and WSL improvements) and works here as of git bash 2.28 and Windows build 21296, and probably for some builds back. If wsl.exe is launched via a pipe (particularly via some external process) versus a tty, PS1 is not set, by-design.

That docker-desktop ends up the default distro has a de-facto landing zone #6024, and is unrelated to the OP.

Computer names with an emoji is LZ #2442 for lack, also unrelated.

If there are other scenarios where the /bin/bash $PS1 prompt does not appear on 19042 or better using wsl.exe, please spin up a new issue following the template or feel encouraged to explore further in discussions. Thanks for everyone's input on this issue.