Repository navigation
Feature requests #1099
Description
Bash on Ubuntu on Windows is an awesome tool. But I think it will be a perfect tool if some features were supported in future.
- user-defined color and font defination: you know changing the default font and color scheme in cmd/powershell is very difficult.
- mouse support: when using vim/emacs, mouse scrolling is important if editing a large file.
- clipboard shortcut is not supported well: I guess this is a bug (maybe).
Reacted by Tobi Reif, Justin O'Neill, Jorge Chayan, Brian Bulkowski, Rod Treweek, Bradley Bauer and Chirishman
Activity
fpqc commentedon Sep 19, 2016
All of these things will probably be available in the future and are already on Uservoice related to the planned upgrades to conhost.
The other option is the project https://github.com/mintty/wsltty
Which uses a cygwin terminal-aware bridge to replace the conhost-only bash.exe. If you run the wslbridge directly, it is almost exactly like running bash.exe (the terminfo used is the one for cygwin's bash (cygbash?) running as a Windows console program instead of xterm, used by bash.exe). Microsoft's bash.exe, I think, tries to parse or convert some of the xterm escape sequences, and this is where a lot of the bugs seem to be coming from.
When you run the wslbridge in mintty, mintty identifies itself as xterm-256color, and the wslbridge will pipe it unconverted xterm escape sequences through a different and non-console interface, I think (tested it a bit, and I wasn't getting raw escapes printed, not sure why that is, but could be related to the fact that the conhost support for escape sequences is actually outstripping what bash.exe is letting through).
By the way, the correct place to put this is on the WSL uservoice
lioupayphone commentedon Sep 19, 2016
Cool!
therealkenc commentedon Sep 21, 2016
wsltty is a great project. Mintty supports Sixel, which means libsixel works. So... xterm in Xsixel on Bash on UoW in Mintty is possible. Which is wrong. So very very wrong.
zadjii-msft commentedon Sep 27, 2016
Whadda you know, give them true color, and they ask for sixel support. Next I'm guessing you'll want 3D video support directly to the console? :P
I kid, I kid. In all seriousness:
fpqc commentedon Sep 27, 2016
Mike Griese (@zadjii-msft) I think that the ConEMU guy has already figured out a way to hook conhost to grab mouse escape sequences. Presumably if he can do it with at-runtime hooking, it's possible to do with access to the Windows sourcecode =].
Also, he may also have gotten sixels to work. He's got image thumbnail previews running in the FAR manager (or maybe he's doing it with a dirty and horrible hack!)
Good luck!
therealkenc commentedon Sep 28, 2016
YouTube videos stream okay in mintty, though the palette based protocol could suckless (I still love the Ballmer video). The GL demo works okay too, though agreed it could be faster. OpenGL extensions after someone decides what numbers to put in the new CSI codes and pushes a PR to mintty... 😜
neurogenesis commentedon Oct 7, 2016
One of the reasons I switched to Macs in the first place was iTerm. The native support for Linux terminals, ssh/scp and all the BSD & GNU goodness of tools like grep / awk / sed.
Up to that point I had been using cygwin + local ssh server + putty to localhost. This worked, but obviously wasn't ideal.
Would really love to see a terminal on the windows OS that has the functionality of iTerm (windows, tabs, tmux support, profiles, triggered events, regex searches, etc.). Would love it if MS would just throw some $$ and resources at the iTerm project for a port. Being able to use the same terminal app across Mac and Win would be fantastic.
fpqc commentedon Oct 7, 2016
ives (@neurogenesis) Eh? I'm sure we'll see tabs sooner or later, and I think it's very likely that we'll be able to run tmux in WSL in conhost, then the Windows-side cmd or powershell in tmux (you can already do this with cbwin if you really want).
neurogenesis commentedon Oct 9, 2016
Sorry, my bad for not going into detail with the additional functionality that a terminal app like iTerm offers.
Multiple native panes in the same window (not just tabs). The regex searches & highlighting (useful for highlighting incoming events), ability to dynamically switch profiles with keyboard shortcuts (or automatically switching color profiles when running sudo or connecting to a different host). Rich support for fonts and terminal colors. Configurable hot keys / key mapping.
Instead most win options are little better than a DOS cmd prompt window (with a handful of improvements inherited from powershell, like finally supporting window resizing).
I applaud the better support for native-ish access to Linux shells and utilities. But there is still a huge gap in terminal usability on the windows platform.
fpqc commentedon Oct 9, 2016
ives (@neurogenesis) You can run gnome-terminal or tilda or urxvt with an X11 server like vcXsrv, although they are atm a bit buggy.
neurogenesis commentedon Oct 9, 2016
I think ConEmu is probably the closest to iTerm. Good enough for the short-term, and hopefully some of their features will keep pace with iTerm.
Still some issues with login and shell selection though (not terminal related but more just the entrypoint into the subsystem. I noticed there was a feature request for full shell login support. What's the roadmap look like for BashOnWindows?
fpqc commentedon Oct 9, 2016
ives (@neurogenesis) More syscalls, more sockopts, more ioctls, better FS performance.
Oh and they're trying to get network interface enumeration and interaction working bc nodejs and Ruby. That's one of their big near-term goals.
They just gor inotify working on DriveFS and before that was chroot support.
alatnet commentedon Nov 16, 2016
Well, since this is a feature request for WSL.
Can I suggest a way to update the subsystem without having to join the insider program?
So for those that are running a stable RTM (or something like that) version of win 10 can easily update the subsystem and gain the features of newer versions of the subsystem like the windows interop.
EDIT: Oh yea! and also add in a feature that allows for NTFS based symlinks to work under the subsystem. It looks like if you created a symlink within windows it doesnt show up in the subsystem. dont know if it does it in reverse though.
Nogitsune101 commentedon Dec 16, 2016
Personally I'd like to see more access to networking components. A large amount of the issues I've run into seem to have been network related. Some kind of Windows side network mapping configuration utility for bash would be ideal allowing for virtual network adapters in linux that can be bridged to windows and alternative ip addresses. I think this would solve some of the port conflict issues I'm having with server services I use. localhost could then remain for Windows but I could assign 127.0.1.1 or even 192.168.0.201 to WSL. If you could register hostnames into Windows that would also save me a trip to the hosts file in Windows too.
Extending functionality in some languages that don't quite have the tools built for them involve calling calling console commands (These are generally avoided because of security issues/compatibility) but some third party libraries do this and not having access to all standard linux commands in /usr/bin can be a headache. If ifconfig doesn't work, I wonder what other things don't work . . .
Having Windows drive mount points in /mnt/ is nice, it is more useful to have them in dev to be mounted wherever they are needed using fstab. For now linking them is an alternative, but I find it annoying (and I haven't tested but probably doesn't work if symlinks are not allowed in services).
This one is a long shot, but since we are talking integration, adding NFS support to Windows 10 Pro or including it in the developer tools for WSL would be really really nice. Currently, this is only available in Windows 10 Enterprise.
I apologize in advance if I'm repeating anything already said but I'd really like to switch off Virtualbox for development . . . so . . . waiting patiently.
WSLUser commentedon Feb 2, 2018
Mike Griese (@zadjii-msft)
All kidding aside, it would be great if this was a reality, not just for WSL but Powershell and maybe CMD. I don't want have to do all that leg work of installing Cygwin, then wslbridge, then wsltty. I feel that's too much effort plus I'm installing something that I could use instead of WSL. I rather not install Cygwin at all. I created a Uservoice requesting this native support under the Console/Terminal label since this pertains to terminal capabilities.
fpqc commentedon Feb 2, 2018
WSLBridge is a one step installation..
fpqc commentedon Feb 3, 2018
wsltty and conemu now support native-launch of wslbridge without installing or maintaining a cygwin installation. ConEmu has a default task now that works perfectly (it launches wslbridge through its built-in cygwin bridge).
WSLUser commentedon Feb 4, 2018
Thanks for educating me. I didn't realize it was all-together in one install. Trying to recreate the above shown image of sixel using wsltty. Looks like a few more steps are needed for sixel anyways. Still the Windows Console can still do native support for it, even if it's not installed by default. Powershell would probably need to do something so they could just
gitlibsixel but as long as the underlyingconhostsupports it, I'd say we are good.fpqc commentedon Feb 4, 2018
Conhost doesn't support sixels. WSLbridge connects a pty through tcp rather than to a conhost instance. Conemu has a native bridge that takes a cygwin pty (this is what wslbridge provides) and connects to it. Wsltty connects Mintty to the same cygwin pty. Neither method goes through conhost.
wslbridge does launch conhost and hides it, but this is likely no longer necessary since background instances of WSL are now allowed.
WSLUser commentedon Feb 4, 2018
I was saying Conhost doesn't support sixels. That's what I would like to see changed. Basically I want wsltty to become useless to WSL. Anything wsltty can do, I think MS should make the console do. This is more than just sixels of course but that would be a starting point.
bitcrazed commentedon May 22, 2018
Thanks for the asks, but please only include one bug/ask per issue - it's difficult to effectively manage multiple asks/issues in one thread.
In Creators Update (1703), we:
In Win10's Console in Fall Creators Update (1709), we:
In Win10 Spring 2018 Update (1803), we:
Therefore, closing this issue for now. If you have further issues or asks, please open new issues (or comment on existing issues) in our Console Issues repo.