bash not found - wsl

Question

bash not found - wsl

asaf400 opened this issue 6 years ago · comments

Windows Version: 10.0.15063 - 1703 (Creators Update)

Executables

Version of bash-debug: 0.3.2
WSL bash.exe Version: 10.0.15063.0
WSL bash version: 4.3.48(1)-release
WSL bashdb version: bashdb, release 4.3-0.91
WSL Distro: Ubuntu 16.04.5 LTS (should be the default)

Output of following commands (on windows, execute them in Command Prompt or PowerShell):

where bash
C:\Users\asaf.levy>where bash
C:\Windows\System32\bash.exe

code --version
C:\Users\asaf.levy>code --version
1.27.2
f46c4c469d6e6d8c46f268d1553c5dc4b475840f
x64

bash -c 'uname -a; for P in bash bashdb cat mkfifo pkill; do echo ---; which -a $P; command $P --version; done'
C:\Users\asaf.levy>bash -c 'uname -a; for P in bash bashdb cat mkfifo pkill; do echo ---; which -a $P; command $P --version; done'
Linux AsafL-T450 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
---
/bin/bash
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
---
/usr/bin/bashdb
bashdb, release 4.3-0.91
---
/bin/cat
cat (GNU coreutils) 8.25
Written by Torbjörn Granlund and Richard M. Stallman.
---
/usr/bin/mkfifo
mkfifo (GNU coreutils) 8.25
Written by David MacKenzie.
---
/usr/bin/pkill
pkill from procps-ng 3.3.10

NOTE: I allowed myself to remove all the Licensing text lines (for readability)

Debug output

No debug output is given, only the message box error.
My launch.json looks like:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "bashdb",
            "request": "launch",
            "name": "Bash-Debug (hardcoded script name)",
            "cwd": "${workspaceFolder}",
            "trace": true,
            "showDebugOutput": true,
            "program": "${workspaceFolder}/ssm-cleanup.sh",
            "args": []
        },
        {
            "type": "bashdb",
            "request": "launch",
            "name": "Bash-Debug (select script from list of sh files)",
            "cwd": "${workspaceFolder}",
            "trace": true,
            "showDebugOutput": true,
            "program": "${command:SelectScriptName}",
            "pathBash": "C:\\Windows\\System32\\bash.exe",
            "args": []
        }
    ]
}

Details

After the latest updates, Debugging bash in vscode on windows 10 ontop the wsl has stopped working,
Probably due this commit: 3bbc0e8 which made it into 0.3.1+

Screenshots:
default config
override config
launch.json + terminal showing bash

before that debugging worked flawlessly (apart the known limitation),
now I see some changes have been made and a new argument\property called 'pathBash' is added,
but I couldn't find documentation about it..

Bash.exe is 100% in Windows's PATH, as it resides in it's default location, and works when openning from cmd.exe, or from vscode..

Also, Attempting to manually set the 'launch property' 'pathBash' to the actual location on my version on windows, which is the old path ("C:\Windows\System32\bash.exe" - with double \ in launch json) Fails.
Tried the different launch configuration options as well, no luck..

so Bash Debug extension is broken on older windows 10, where it worked before

For now my only workaround is to use the older vsix before the changes (v0.2.2 as it seems like)

How can I further help promote this issue?
Thank you very much for this extension, IT IS AWESOME! I greatly appreciate the work done on this..

Michał · Answer 1 · Wed Oct 03 2018 00:27:22 GMT+0800 (China Standard Time)

Hi,

The pathBash is not purely for selecting bash in linux filesystem - either leave it empty or select for example /bin/bash. According to wsl docs, bash.exe is deprecated for wsl.exe and newest changes conform to that (its all automated inside extension).

So please remove the pathBash and check Debug console. Also, verify that wsl.exe starts via cmd or powershell (just type wsl).

Michał · Answer 2 · Wed Oct 03 2018 01:36:02 GMT+0800 (China Standard Time)

After carefully reading this report, it could be related to old windows 1703. Please verify the wsl.exe if it works, then we can check other stuff.

Also, I prepared a version of extension that uses bash.exe instead of new wsl.exe, while keeping all new functionality (though this cannot be published to marketplace):
bash-debug-0.3.2.vsix.zip

Seems that wsl before 1709 was beta, please check in cmd for example:
wsl.exe bash -c "bashdb somescript.sh"

Asaf Levy · Answer 3 · Wed Oct 03 2018 20:52:50 GMT+0800 (China Standard Time)

Yes, That's exactly it, I have no 'wsl.exe' on my windows version, only the deprecated 'bash.exe',
I forgot to write that as well in the original comment, sorry..

Thanks for Building a special version, I'll try it and comment when I have the results..

Asaf Levy · Answer 4 · Wed Oct 03 2018 23:33:53 GMT+0800 (China Standard Time)

Terminal output:

cd . ; bash.exe -c "cd \"/mnt/c/gits/scratch\"; while [[ ! -p \"/tmp/vscode-bash-debug-fifo-15431\" ]]; do sleep 0.25; done;                    \"bash\" \"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir/bashdb\" --quiet --tty \"/tmp/vscode-bash-debug-fifo-15431\" --tty_in \"/tmp/vscode-bash-debug-fifo-15431_in\" --library \"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir\" -- \"/mnt/c/gits/scratch/ssm-cleanup.sh\" "

[root@AsafL-T450 scratch]# cd . ; bash.exe -c "cd \"/mnt/c/gits/scratch\"; while [[ ! -p \"/tmp/vscode-bash-debug-fifo-15431\" ]]; do sleep 0.25; done; \"bash\" \"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir/bashdb\" --quiet --tty \"/tmp/vscode-bash-debug-fifo-15431\" --tty_in \"/tmp/vscode-bash-debug-fifo-15431_in\" --library \"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir\" -- \"/mnt/c/gits/scratch/ssm-cleanup.sh\" "

 O p e r a t i o n   n o t   s u p p o r t e d .
 P r e s s   a n y   k e y   t o   c o n t i n u e . . .

Debug Console:

4:46:04 PM, 10/3/2018
From client: initialize({"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"bashdb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us"})
To client: {"seq":0,"type":"response","request_seq":1,"command":"initialize","success":true,"body":{"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":false,"supportsEvaluateForHovers":true,"supportsStepBack":false,"supportsSetVariable":false}}
From client: launch({"type":"bashdb","request":"launch","name":"Bash-Debug (hardcoded script name)","cwd":"C:\\gits\\scratch","showDebugOutput":true,"trace":true,"program":"C:\\gits\\scratch/ssm-cleanup.sh","args":[],"pathBash":"bash","pathBashdb":"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir/bashdb","pathBashdbLib":"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir","pathCat":"cat","pathMkfifo":"mkfifo","pathPkill":"pkill","__sessionId":"115e732a-b621-4ed9-870a-954205a311e2"})
To client: "runInTerminal"({"title":"Bash Debug Console","cwd":".","args":["bash.exe","-c","cd \"/mnt/c/gits/scratch\"; while [[ ! -p \"/tmp/vscode-bash-debug-fifo-15431\" ]]; do sleep 0.25; done; \t\t\t\"bash\" \"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir/bashdb\" --quiet --tty \"/tmp/vscode-bash-debug-fifo-15431\" --tty_in \"/tmp/vscode-bash-debug-fifo-15431_in\" --library \"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir\" -- \"/mnt/c/gits/scratch/ssm-cleanup.sh\" "]}), timeout: 10000
To client: {"seq":0,"type":"event","event":"output","body":{"category":"stderr","output":"::PROXYID::2127\n"}}
::PROXYID::2127

Pressing any key, results in the terminal returning to normal (bash)

I remembered that I configured my vscode to run the wsl bash as default shell terminal (It's in the README for the extension),
I removed that from my config, and now it's using PS, and working.. (didn't check for white-space issues though..)

Michał · Answer 5 · Wed Oct 03 2018 23:42:02 GMT+0800 (China Standard Time)

To be clear - is it now fully working?

Argh, I see what you mean. So by coincidence, the newer version of windows that i am using (1803) allows to run wsl.exe from linux:

michal@bash$ wsl.exe bash -c "echo test"
test

I need to think this trough a bit...

Asaf Levy · Answer 6 · Thu Oct 04 2018 16:33:55 GMT+0800 (China Standard Time)

Running .exe within wsl is allowed on my windows version as well, interoperability It's called, but probably due to the recent changes in pipe support and pty allocation etc..; The newer version of the extension I believe can only feasibly be designed to work on the latest wsl.exe, and not the bash.exe, Too many changes made on Microsoft's WSL side of things..

Here's my results from the same command you successfully ran:

[root@AsafL-T450 ~]# bash.exe bash -c "echo test"
Unable to translate current working directory. Using C:\Users\asaf.levy

 O p e r a t i o n   n o t   s u p p o r t e d .
 P r e s s   a n y   k e y   t o   c o n t i n u e . . .

I've also tried other variations of this, tried to tell bash.exe to actually run a command via arguments, from within wsl bash..

But, When I tried just bash, it worked:

[root@AsafL-T450 windows]# bash -c "echo test"
test

So if you can assume the extension user already setup bash.exe as default terminal, and that there's no special requirement for using bash.exe and not just bash, you can just launch the terminal and issue the command with 'bash -c', no need for bash.exe, or wsl.exe, unfortunately I cannot further investigate this, as this command

cd . ; bash.exe -c "cd \"/mnt/c/gits/scratch\"; while [[ ! -p \"/tmp/vscode-bash-debug-fifo-15431\" ]]; do sleep 0.25; done;                    \"bash\" \"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir/bashdb\" --quiet --tty \"/tmp/vscode-bash-debug-fifo-15431\" --tty_in \"/tmp/vscode-bash-debug-fifo-15431_in\" --library \"/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir\" -- \"/mnt/c/gits/scratch/ssm-cleanup.sh\" "

is compiled within the extension, and as much as I'd like to I do not have the time to compile the extension myself with changes and test, but I do have time to just test..

With PS as default terminal, I've tried going through breakpoints, which works, watches work as well, but local variables do not get detected, only $? and $PWD are detected.. (even though In debug console, I see 'To client' messages with newly assigned variables)

Michał · Answer 7 · Thu Oct 04 2018 18:17:36 GMT+0800 (China Standard Time)

There are some issues that make this fix especially tricky:

Related to wsl issue:

there needs to be a way to select proper bash version within linux, ie: /bin/bash vs /usr/bin/env/bash, which was the intent of recent pathBash change in marketplace version of extension, so WSL exe name/location needs to be separate setting or hardcoded
bashPath is not used only via terminal, but also to verify variables and there is also separate process to read message pipes for debugger (separate spawn process calls)
I would not like to make assumption about terminal unless i find a way to properly inform user about wrong terminal setting (possibly also auto change to bash terminal), not sure how to do that yet
lot of the extension code is WSL handling, so I would like not to extend this too much - especially for beta WSL

Local variables are currently hardcoded to show only $? and $PWD and you mentioned they are shown. Did you mean watch variables are not shown?

Currently to nr 1. issue i see following fixes:

[IF WSL] check if terminal is bash, if not -> inform user and give some UI interaction to change terminal in workspace settings (in this case no need to run exe in terminal, because terminal is already in WSL)
expand terminalKind to integrated | external | debugConsole, where debugConsole would work as in previous versions (which would be terminal independent, but no stdin like in older versions)

I think I will start with extending terminalKind #95 in this case, because all of the OSes will benefit from that.

Michał · Answer 8 · Thu Oct 04 2018 20:09:56 GMT+0800 (China Standard Time)

Test version with debugConsole terminalKind:
https://github.com/rogalmic/vscode-bash-debug/releases/download/untagged-dc098ff29d07ab9e068d/bash-debug-0.3.2.vsix

Asaf Levy · Answer 9 · Thu Oct 04 2018 23:04:17 GMT+0800 (China Standard Time)

Latest comment vsix produces the 'bash not found' error, as with original issue comment (pathBash)
maybe you reset you're working dir, and forgot :) ?

To test correctly, we need both changes: the pathBash to be bash.exe, and terminal to be just bash
instead of the now 'master' defaults which are pathBash as wsl.exe and terminal as wsl.exe

Michał · Answer 10 · Thu Oct 04 2018 23:16:31 GMT+0800 (China Standard Time)

You have to use terminalKind to debugConsole in launch.json, then it should work with WSL beta (without stdin).

Unless i misunderstood and there is no wsl.exe, just bash.exe in this old windows version? I assume its not there (you pasted only output from bash.exe). I can prepare a build with this debugConsole + the "hacked" changes for wsl.exe->bash.exe, but this will not be published to marketplace...

pathBash will not go back to bash.exe, since from extension release 3.* it is purely for linux/wsl path to bash. All of the WSL logic is handled internally by extension and uses wsl.exe.

Asaf Levy · Answer 11 · Thu Oct 04 2018 23:49:18 GMT+0800 (China Standard Time)

Sorry I've missed the first post by you, before the rebuild:

Local variables are currently hardcoded to show only $? and $PWD and you mentioned they are shown. Did you mean watch variables are not shown?

no, I mean just local variable, I remember they showed any variable that's assigned, even without watching, I might be wrong about that..

there needs to be a way to select proper bash version within linux, ie: /bin/bash vs /usr/bin/env/bash, which was the intent of recent pathBash change in marketplace version of extension, so WSL exe name/location needs to be separate setting or hardcoded

I now understand what pathBash is for, It's to detect where bash is within the wsl environment, due to changes I've not been aware of in the Windows Marketplace for WSL products..

Unless i misunderstood and there is no wsl.exe, just bash.exe in this old windows version? I assume its not there (you pasted only output from bash.exe). I can prepare a build with this debugConsole + the "hacked" changes for wsl.exe->bash.exe, but this will not be published to marketplace...

Indeed that is that case, there is no wsl.exe in the old windows version, there's only bash.exe, which isn't actually bash, but a some kind of wsl wrapper which initializes the environment..

I can prepare a build with this debugConsole + the "hacked" changes for wsl.exe->bash.exe, but this will not be published to marketplace...

That would be an excellent solution, if it would work, but we havn't tried it yet, so far as I understand:
1st build you published here, is the 'changes for wsl.exe->bash.exe' and the 2nd one is

I've already stated before, sorry if it wasn't clear enough that Windows Version: 10.0.15063 - 1703 Doesn't have the wsl.exe, and only uses bash.exe..

so, in summary, we should try a version of the extension that has wsl.exe replaced with bash.exe, BUT when sending commands to terminal, do not use bash.exe and only use bash, and where pathBash is fixed as it is with the first special build you did:

Also, I prepared a version of extension that uses bash.exe instead of new wsl.exe, while keeping all new functionality (though this cannot be published to marketplace):
https://github.com/rogalmic/vscode-bash-debug/files/2438998/bash-debug-0.3.2.vsix.zip

Michał · Answer 12 · Fri Oct 05 2018 00:17:07 GMT+0800 (China Standard Time)

This one has first fixes + debug console:
bash-debug-0.3.2.vsix.zip

As for the variables, i changed the list to be shorter for performance reasons, but it was never dynamic. This task to find true local variables is in TODO list...

Asaf Levy · Answer 13 · Fri Oct 05 2018 00:27:19 GMT+0800 (China Standard Time)

Nope :(
Still the pathBash error..

I Just found out that anyone can upgrade thier win10 to the latest October update:
https://www.microsoft.com/software-download/windows10

But I'm not sure if we want to do that, or still work to solve this issue for those still waiting on the official 'windows update' method, and not the manual method..

EDIT: Just found that that the first fixes aren't working as well, for some reason...
I uninstalled the extension and reinstall via the 'Install from vsix' option and that's still pathBash, but Im sure one of the newer version you've sent me here has fixed the pathBash problem

Michał · Answer 14 · Fri Oct 05 2018 00:32:40 GMT+0800 (China Standard Time)

Please uninstall current version and restart VSCode, the install the extension manually (I had issue with this). This one definitely contains the previous code that worked for you with powershell.

Asaf Levy · Answer 15 · Fri Oct 05 2018 00:44:53 GMT+0800 (China Standard Time)

YESSS, that's it !!!

I've seen it also, deleted files return due to some wierd lock in the filesystem \ wsl, Completly closing and Opening the VSCode each uninstall \ install worked, and the latest file in you're comment works with these settings:

launch.json

        {
            "type": "bashdb",
            "request": "launch",
            "name": "Bash-Debug (hardcoded script name)",
            "cwd": "${workspaceFolder}",
            "showDebugOutput": true,
            "terminalKind": "debugConsole",
            "trace": true,
            "program": "${workspaceFolder}/ssm-cleanup.sh",
            "args": []
        }

User Settings

    "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe",
    "terminal.integrated.shell.linux": "bash",

Watches works (as with PS), Stepping works, stdin doesn't work, but that's excpected since that feature relies on proper wsl.exe features..?

read varname

echo $varname

Code halts on first line:

stty: 'standard input': Inappropriate ioctl for device
stty: 'standard input': Inappropriate ioctl for device

/bin/bash: line 1: 17165 Killed                  "bash" "/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir/bashdb" --quiet --tty "/tmp/vscode-bash-debug-fifo-12160" --tty_in "/tmp/vscode-bash-debug-fifo-12160_in" --library "/mnt/c/Users/asaf.levy/.vscode/extensions/rogalmic.bash-debug-0.3.2/bashdb_dir" -- "/mnt/c/gits/scratch/stdin.sh"

Michał · Answer 16 · Fri Oct 05 2018 00:50:06 GMT+0800 (China Standard Time)

Generally when outputting to Debug Console there is no stdin (its not WSL issue in this case). Maybe I can figure something out with this eval input line syntax in the bottom of Debug Console, but this will take time + might be too hack-ish.

When i add this to master, I will also update this build here and let you know.

Asaf Levy · Answer 17 · Fri Oct 05 2018 00:51:54 GMT+0800 (China Standard Time)

STDIN Works!!

Setting: "terminalKind": "external"
Makes a console windows pop out, and when typing there, the values get captured :) 👍
Screenshot

Edit after reading you're comment:
without any terminalKind it still tries to run bash.exe from bash, which is already default terminal, so yeah maybe some focus on that and or what you said could make it work..

Michał · Answer 18 · Fri Oct 05 2018 00:54:04 GMT+0800 (China Standard Time)

Hmm, probably that is because only integrated console is bash:

"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe",
"terminal.integrated.shell.linux": "bash",

But not sure :)

Asaf Levy · Answer 19 · Fri Oct 05 2018 00:59:55 GMT+0800 (China Standard Time)

Wait, so Is that not a requirement?
Should I not set my 'terminal.integrated.shell.*' to bash?

Without it, stdin also works, but the terminal is Powershell

Michał · Answer 20 · Fri Oct 05 2018 01:12:00 GMT+0800 (China Standard Time)

Default terminalKind is integrated (which can be set in preferences). This means that it tries to run bash (which would be preferred), but since you have this beta WSL it fails with this interop error.

For this beta WSL, the simplest thing is to use terminalKind: debugConsole, which in practice is not terminal, but just debug output. The downside: no stdin, but there is a workaround here .

If i find design way to pass input to debugConsole, I will update build here.

As a sidenote: biggest issue with powershell is qouting :

microsoft/WSL#3533
Now debugadapter has no way of selecting or knowing which shell will be run, so it assumes some sane one that accepts linux like double quoting.