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.
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.-