You seem to completely miss the point of what they did. It is not a simple Bash recompilation for Windows. It is a way to run Linux (Ubuntu) binaries on Windows.
back
3 comments
Well I, for one, think he has a point. Part of what makes the shell so useful on Linux is, say, highlight-to-select. When the CMD.EXE doesn't understand line breaks in copied text, it's substantially crippled. You need a proper terminal to take advantage of a proper shell. They go hand-in-hand.
Nothing about what they implemented prevents you from using a different terminal.
Also cmd.exe on Windows 10 does support line breaks in copied text from what my minor test just showed.
Selection, copying, wrapping etc. has been fixed in the Win10 version of the console host.
In pervious versions you could always use another console like Console2, but now it's built in (although the third party options still have more features than the new built in one).
My point is that you need a terminal program (like putty or iTerm2 on OS X for example) to get all the benefits.
He says it mostly works in cmd.exe, and they're working on getting things like screen/tmux working too.
If a fully-compatible terminal emulator doesn't exist yet (I have no idea) I bet there will be one within a year.
conhost (the black box that typically runs cmd.exe) is a terribly shitty terminal emulator. My biggest gripe with Windows has been the lack of a decent pseudoconsome system that would allow an ecosystem of terminal emulators to developer, as one has for POSIX-ish systems.
> My biggest gripe with Windows has been the lack of a decent pseudoconsome system that would allow an ecosystem of terminal emulators to developer, as one has for POSIX-ish systems.
This has been up since the turn of the century:
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ca...
The demonstrators in the Microsoft video do warn that they will be avoiding some of the holes of the system in their demonstration. One is very briefly visible at 08'13", before the demonstrator rapidly clears the screen (again), when they run apt-get to install git:
E: Can not write log (Is /dev/pts mounted?) - openpty (2: No such file or directory)
The old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) has pseudo-terminals with both BSD and System 5 access semantics, in comparison.
* https://technet.microsoft.com/en-gb/library/bb497016.aspx
* https://technet.microsoft.com/en-gb/library/bb463219.aspx
Moreover, a Windows console window that is the controlling TTY of a POSIX program in that subsystem has the POSIX cooked input mode with local echo, and generates escape sequences for extended keys.
What about ConEmu? Works well for me, I especially like the Quake-style dropdown terminal option...
ConEmu looks nice; it came out after I switched from Windows to Linux, so I've never tried it. I like the idea of hooking the console API functions; before I stopped using Windows, I was working independently on a similar API-hooking system that talked to the Cygwin pty layer instead of to a custom terminal.
With a real pty, you'd be able to use any Windows console program with mintty, sshd, Emacs term-mode, or whatever else you wanted, transparently. I regret not having a chance to finish that work.
It doesn't sound much different than a built in VM with a some optimizations. Just more bloat for windows I suppose.