Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature requests #1099

Closed
lioupayphone opened this issue Sep 19, 2016 · 21 comments
Closed

Feature requests #1099

lioupayphone opened this issue Sep 19, 2016 · 21 comments
Labels

Comments

@lioupayphone
Copy link

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.

  1. user-defined color and font defination: you know changing the default font and color scheme in cmd/powershell is very difficult.
  2. mouse support: when using vim/emacs, mouse scrolling is important if editing a large file.
  3. clipboard shortcut is not supported well: I guess this is a bug (maybe).
@fpqc
Copy link

fpqc commented 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
Copy link
Author

Cool!

@therealkenc
Copy link
Collaborator

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.

wsl-xterm-xsixel

@zadjii-msft
Copy link
Member

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:

  1. I'd love to have a better way of doing that. You're absolutely right that the current "Colors" dialog is a little bit terrible. It's definitely pretty high on my personal wants list, but not necessarily super high on the backlog (relatively speaking)
  2. Yea that'd be cool. I'd be into that. stares nervously at Insiders cadence
  3. That's a little tricky. Everyone has their own prefered way of copy-pasting - Ctrl-C/V, Right Click, Middle Click, Ctrl+Shift-C/V, etc. These are all options I'd love to add to the properties sheet if we get a chance to get around to updating it, so, yes, it's definitely on the backlog.

@fpqc
Copy link

fpqc commented Sep 27, 2016

@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
Copy link
Collaborator

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
Copy link

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
Copy link

fpqc commented Oct 7, 2016

@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
Copy link

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.

On Oct 7, 2016, at 17:15, fpqc [email protected] wrote:

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


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@fpqc
Copy link

fpqc commented Oct 9, 2016

@neurogenesis You can run gnome-terminal or tilda or urxvt with an X11 server like vcXsrv, although they are atm a bit buggy.

@neurogenesis
Copy link

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
Copy link

fpqc commented Oct 9, 2016

@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
Copy link

alatnet commented 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
Copy link

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
Copy link

WSLUser commented Feb 2, 2018

@zadjii-msft

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

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
Copy link

fpqc commented Feb 2, 2018

WSLBridge is a one step installation..

@fpqc
Copy link

fpqc commented 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
Copy link

WSLUser commented 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 git libsixel but as long as the underlying conhost supports it, I'd say we are good.

@fpqc
Copy link

fpqc commented 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
Copy link

WSLUser commented 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
Copy link
Contributor

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.

  1. user-defined color and font defination: you know changing the default font and color scheme in cmd/powershell is very difficult.
  2. mouse support: when using vim/emacs, mouse scrolling is important if editing a large file.
  3. clipboard shortcut is not supported well: I guess this is a bug (maybe).

In Creators Update (1703), we:

  1. Added 24-bit color support
  2. Added mouse scroll & click support

In Win10's Console in Fall Creators Update (1709), we:

  1. Updated the default Console color palette (on new Installs) for the first time, improving colors on LCD screens, improving contrast, etc.
  2. Shipped a ColorTool that allows you configure the Console's color palette to colors specified in theme files

In Win10 Spring 2018 Update (1803), we:

  1. Added CTRL + SHIFT + [C|V] Copy/Paste support for Linux Console instances.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants