Slashdot Mirror
Windows 10 Upgrade Bug Disabled Cntrl-C In Bash (infoworld.com)
An anonymous reader quotes InfoWorld:
A massive set of changes to the Windows Subsystem for Linux (WSL) was rolled into Windows Insider build 15002... If this is any hint, Microsoft's goal is nothing short of making it a credible alternative to other Linux distributions... Some of the fixes also implement functionality that wasn't available before to Linux apps in WSL, such as support for kernel memory overcommit and previously omitted network stack options. Other changes enhance integration between WSL and the rest of Windows...
[O]ne major issue in build 15002 is that Ctrl-C in a Bash session no longer works. Microsoft provided an uncommon level of detail for how this bug crept in, saying it had to do with synchronization between the Windows and Bash development teams. The next Insider build should have a fix. But for people doing serious work with Linux command-line apps, not having Ctrl-C is a little like driving a car when only the front brakes work.
[O]ne major issue in build 15002 is that Ctrl-C in a Bash session no longer works. Microsoft provided an uncommon level of detail for how this bug crept in, saying it had to do with synchronization between the Windows and Bash development teams. The next Insider build should have a fix. But for people doing serious work with Linux command-line apps, not having Ctrl-C is a little like driving a car when only the front brakes work.
> I think I'm gonna increase my MSFT position just in case.
Best of luck with that. I've always done mutual funds instead of trying to pick. I often discussed this with my best friend, who would always pick stocks. One day, in early 2008, he told me that rather than picking one company he had made a can't-lose buy: both Intel and AMD. Being the only two processor manufacturers with any significant market share, one of them would have to do well! Of course that was just about the time Android was released and most processor sales started to be ARM devices, neither Intel nor AMD.
Programs trapping Ctrl-C as an exception are exceptionally lazy - there should be a more "front end" way to quit. Originally Ctrl-C was just to kill, not to gracefully shut-down.
In a purely TTY environment there's usually only CTRL-C and CTRL-\ to generate signals (SIGINT and SIGQUIT) that processes can catch. (CTRL-Z generates SIGSTOP which can't be caught.) What's so lazy about using one of those? Of the two, CTRL-C is clearly the most appropriate if supported by the environment. What do you mean by "front end" here? If you mean some non-TTY-based mechanism then, sorry, that's not always an option.
I know for myself, and many others at the companies I have worked for -- THere are a signifcant number of people who use Macbooks, but run Windows on them. As I type here, It's a macbook Pro Running Windows 10.
The hardware runs Windows significantly better than any natively developed Windows notebook. Probably becasue drivers can be written to only a single known configuration and that can be optimized.
WHen running multiple VMs, and IDEs on Windows on Macbook Pro hardware -- it simply outclasses the same setup on alternatives.
But either way, at our office, more than half (500+ users) all run Windows as their primary OS on the Macbooks. Most workers don't know that they can even boot into Mac OSX (minimally sized partition, as even the Engineers don't even boot into OSX)
Once I installed Windows 7 on a Macbook Pro -- I never went back to Windows-first hardware.
1. Buy MacBook
2. Install Windows.
3. Have a kick ass windows box for development and gaming.-