-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bash not found - wsl #93
Comments
Hi, The So please remove the |
After carefully reading this report, it could be related to old windows 1703. Please verify the Also, I prepared a version of extension that uses Seems that wsl before 1709 was beta, please check in cmd for example: |
Yes, That's exactly it, I have no 'wsl.exe' on my windows version, only the deprecated 'bash.exe', Thanks for Building a special version, I'll try it and comment when I have the results.. |
Terminal output:
Debug Console:
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), |
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... |
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:
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:
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
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) |
There are some issues that make this fix especially tricky:
Currently to nr 1. issue i see following fixes:
I think I will start with extending |
Test version with |
Latest comment vsix produces the 'bash not found' error, as with original issue comment (pathBash) To test correctly, we need both changes: the pathBash to be bash.exe, and terminal to be just bash |
You have to use terminalKind to 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. |
Sorry I've missed the first post by you, before the rebuild:
no, I mean just local variable, I remember they showed any variable that's assigned, even without watching, I might be wrong about that..
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..
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..
That would be an excellent solution, if it would work, but we havn't tried it yet, so far as I understand: 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:
|
This one has first fixes + debug console: 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... |
Nope :( I Just found out that anyone can upgrade thier win10 to the latest October update: 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... |
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. |
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
User Settings
Watches works (as with PS), Stepping works, stdin doesn't work, but that's excpected since that feature relies on proper wsl.exe features..?
Code halts on first line:
|
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. |
STDIN Works!! Setting: Edit after reading you're comment: |
Hmm, probably that is because only integrated console is bash:
But not sure :) |
Wait, so Is that not a requirement? Without it, stdin also works, but the terminal is Powershell |
Default terminalKind is For this beta WSL, the simplest thing is to use terminalKind: If i find design way to pass input to debugConsole, I will update build here. As a sidenote: biggest issue with powershell is qouting :
|
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):
Debug output
No debug output is given, only the message box error.
My
launch.json
looks like: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)
The text was updated successfully, but these errors were encountered: