Closed bitcrazed closed 7 years ago
Still works like a charm under wsl-terminal https://github.com/goreliu/wsl-terminal ;-)
Thank you. It'll be great to have that fix in the system. For now, I've mapped CTRL-C to CTRL-P; which is how PR1MOS computers at my university handled 'interrupt' 35 years ago. Can't beat nostalgia.
A fellow Surrey graduate -- small world!
@benhillis Do we have a scheduled release date for this fix? Thanks!
@seancorfield No, we generally don't get notice for when the next insider build gets flighted. And the team here doesn't control it. Ask @donasarkar on twitter maybe.
I'm hoping next week's build has the fix.
Fixed in 15014 it seems. Thank you!
tfw 15014 broke my xbox controller though >.< ( just a warning, it's a known issue )
Does this fix ctrl-z too? I've just upgraded to CU/15063.138, and ctrl-z has stopped working - it used to work in 14393.969, so it is a regression.
@davidmaxwaterman - Thanks for the report. We are looking into it.
Fwiw, I have since noticed it works from within vim, but not in bash.
@davidmaxwaterman - We have found the bug. We are prioritizing it and working to get it fixed. Apologies for breaking such a basic scenario.
Also having ongoing issues with ctrl-z
I also have the Ctrl-z issue. Could you please clarify whether bugs like these would be fixed via Patch Tuesday or whether we would need to join the insider program?
@giech - We are tracking this bug for Patch Tuesday. But general bugs and feature work will only be available through the Insider program (it's a case by case basis). The Ctrl+Z fix is going through the vetting process to get in the patch Tuesday. Difficult to give any ETA's because most of that process is outside our team. We do apologize for the inconvenience this bug has caused.
Thank you Sunil,
I can understand the various reasons fixes take time, and I appreciate the work you are doing.
As a work around you can install something like xfce4-terminal. Ctrl-Z still works there.
Sent from Mail for Windows 10
From: Sunil Muthuswamy Sent: Friday, April 21, 2017 7:48 PM To: Microsoft/BashOnWindows Cc: EricPell; Comment Subject: Re: [Microsoft/BashOnWindows] CTRL+C doesn't work in Bash in Insider build 15002 (#1569)
@giech - We are tracking this bug for Patch Tuesday. But general bugs and feature work will only be available through the Insider program (it's a case by case basis). The Ctrl+Z fix is going through the vetting process to get in the patch Tuesday. Difficult to give any ETA's because most of that process is outside our team. We do apologize for the inconvenience this bug has caused. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
@All - Getting a bug serviced for Creators Update through Patch Tuesday is a bit more involved that we initially thought. We are being informed that balancing business reason for fixing it vs risk is important for servicing. The issue needs to have some critical volume, business justification etc. So, if this bug is something you would like to see fixed for Creators Update, please chime in (maybe add a sentence or two on why this is important to you) and help us get to that critical volume.
Bash On Ubuntu On Windows provides the tools that allow an unmodified Windows installation to be used where a Linux or MacOS OS would be needed. I have personally been very outspoken in the field of astrophysics and astronomy that MS is committed to supporting researchers, as evidenced by their involvement and iterations on issues and features.
As on example, the Cloudy Developers group (nublado.org) now support use of their widely distributed open sourced code with BoUoW. However, these types of "problems" prevent the lead authors from fully endorsing using Windows. The team has to answer to many thousands of current users, and the OS can not get in the way of the code. Being able to reliably execute know, expected basic hot-keys is fundamental to users seeing BoUoW as a viable option to work. The optics of fixing a bug like this are bad at a crucial time when cautious and skeptical users have renewed interest in Windows.
Thank you.
I wonder if someone could change the title of this bug to ctrl-z (since ctrl-c is fixed).
This issue is now tracking Ctrl+Z. The issue is fixed in insider builds but not in CU. I am opening this up so that we can continue the discussion.
@EricPell - Thank you for the explanation. I personally do agree with your assessment, and I am pushing to get this serviced in CU. But, I am facing internal headwinds in that process because not many customers here are asking for this issue to be serviced.
Is the issue because it's not a WSL issue/fix per say, but a change to Windows hot keys? I could see the potential horror screwing that up would cause for all windows machines.
Sent from my Windows 10 phone
From: Sunil Muthuswamy Sent: Monday, May 22, 2017 12:38 AM To: Microsoft/BashOnWindows Cc: EricPell; Mention Subject: Re: [Microsoft/BashOnWindows] CTRL+C doesn't work in Bash in Insider build 15002 (#1569)
@EricPell - Thank you for the explanation. I personally do agree with your assessment, and I am pushing to get this serviced in CU. But, I am facing internal headwinds in that process because not many customers here are asking for this issue to be serviced. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@EricPell - No, this is a very WSL specific fix. But, the servicing process (which is not in the WSL team's control) has it's own servicing bar (ex: volume or % of users affected etc) and currently, this bug is not standing up to the bar. The WSL team is trying to push to get this serviced, but we have to show that many customers are actually asking for a fix.
I'll post this to the reddit group to solicit comments. It's only a few thousand users though.
Sent from my Windows 10 phone
From: Sunil Muthuswamy Sent: Monday, May 22, 2017 1:43 AM To: Microsoft/BashOnWindows Cc: EricPell; Mention Subject: Re: [Microsoft/BashOnWindows] CTRL+C doesn't work in Bash in Insider build 15002 (#1569)
@EricPell - No, this is a very WSL specific fix. But, the servicing process (which is not in the WSL team's control) has it's own servicing bar (ex: volume or % of users affected etc) and currently, this bug is not standing up to the bar. The WSL team is trying to push to get this serviced, but we have to show that many customers are actually asking for a fix. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I for one am very glad that this was fixed for the Insiders Builds because it was a horrible to work around. However, for those who have not received any fixes, because they are running production builds, WSL will not seem like a product which can be trusted. While there is a long tail of users impacted, the intersection of developers running the released version of Windows, is a group you absolutely want to feel satisfied because they can be the biggest critics or fans and you want them cheering for you.
Didn't realize this hadn't been fixed because my main machine is on the insider builds. My secondary machines though are all production releases and not having working ctrl-z ctrl-c, etc is impractical for everyday use.
Saw this on reddit. Come on Microsoft, you guys are doing a great job with WSL, fix this one for us!
Like others said, this fix should go out to the non-insiders, too.
+1 Here's hoping for a quick fix on this.
This fix definitely needs to go to non-Insiders.
While I use vncserver, I'd like the servicing team to be considerate here. So +1.
Yeah, seems like the kind of thing that would really drive people nuts and turn them off from using WSL, especially since it's a regression.
WSL without Ctrl+Z is similar to Windows without right click. You can work around it, but you cannot expect to win any customers with it.
Thanks all for chiming in. The bug has been approved for Creators Update servicing.
@sunilmut That's great news. Thanks for the attention.
I don't think it was in yesterday's updates...was I overly optimistic?
@davidmaxwaterman - Possibly. The fix has to go through the test cycle of the servicing process. I know the fix is on it's way out. Probably, by the end of the month. Thanks for your patience.
I believe the fix was in the latest Patch Tuesday, but the release notes do not mention it: (KB4025342). Could someone please confirm and close the issue, if that is the case?
Just tried to send Ctrl+Z to a sleep 5
on bash. Worked just fine. Thanks for fixing!
Great, thank you both for confirming.
Is there a reason why ctrl+z/c still don't work on ssh?
E.g. try doing ssh ip.you.know.wont.connect
and there's no way to stop it until it times out.
This is a different problem with its own issue.
I found it #2220 but it's closed even though the fix is only on insider builds. Any idea when the fix will be released for production builds?
@kylemacfarlane - The fix will be available in the Fall Creators Update public release.
The Fall Creators Update did not fix the problem. Ctrl-C still kills the bash console window, Ctrl-Z does nothing.
@ivanlan9:
I am able to CTRL+C to kill and CTRL+Z to stop an ssh connection awaiting a response from a non-existent server:
If you have other specific issues, could I ask you to please open a new issue & providing detailed repro steps, etc?
Many thanks.
I realized that the problem was probably not a bug in bash on Windows. Instead of running bash, I'm exec'ing mksh (wish there were a way to chsh). And that means that the original bash process is not an interactive one, thus it doesn't ignore SIGINT. Mksh is passing SIGINT on to the the bash process instead of ignoring it (this is probably either a bug in or an enhancement to mksh) when it's exec'ed.
I was able to work around the problem by inserting 'trap "echo" INT' into my mksh startup script.
Also, Ctrl-Z does the right thing: by "does nothing," I meant that it didn't close the terminal window the way Ctrl-C did. Ctrl-Z on a running process correctly backgrounds the process.
Many thanks for prodding me to think about the issue a bit more. ;-)
wish there were a way to chsh
chsh
has worked since summer of 2017.
Doesn't appear to work. Chsh correctly changed /etc/passwd, but when I logged in, it gave me bash.
@ivanlan9 - Are you running bash.exe, wsl.exe, or the distru launcher binary (ubuntu.exe etc).
Oooh. "C:\Windows\System32\bash.exe ~"
This sounds promising! Please inform me!
Issue: In Windows 10 Insider build 15002, when running Bash.exe, CTRL + chords are not being correctly handled by the Windows Console.
Effect: Users will be unable to terminate Linux apps using CTRL + C, or background running tasks using CTRL + Z, etc. When CTRL + C is hit in Bash, a ‘c’ is displayed in the bash console.
Work-Around(s): Until fixed:
stty intr \^k
. This mapping is per terminal and will have to be done every time bash is launched. Users can include this in their .bashrc if preferredScope: This issue only affects Bash sessions and does not prevent CTRL + C, etc. in other console apps or shells (i.e. Cmd or PowerShell).
For more information on this release, including the many other fixes it DOES include, be sure to read the build 15002 Release Notes.
We apologize for this annoying issue. A fix has been checked-in and will be released ASAP into an up-coming Insiders build.