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

Right-click paste drops characters in WSL #1545

Closed
brusch opened this issue May 3, 2018 · 14 comments
Closed

Right-click paste drops characters in WSL #1545

brusch opened this issue May 3, 2018 · 14 comments

Comments

@brusch
Copy link

brusch commented May 3, 2018

Versions

ConEmu build: 180429 [32]
OS version: Windows 10 x64 version 1803 build 17134.1
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): WSL bash.exe or debian.exe

Problem description

Behavior is quite similar to the one described in #1314
If you paste a text containing spaces it seems that characters are randomly dropped, texts not containing any space character work fine as far as I can see.

Working example

aaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc

Misbehaving example

aaaaaaaaaaaaaaaaabbbbbbbbbbbbb bbbbbbbbbbbbcccccccccccccccccccc

Steps to reproduce

  1. Open a WSL shell, eg. with the config debian.exe -cur_console:p or bash.exe -cur_console:p
  2. Paste a string containing a space character

Actual results

Characters of the pasted text get dropped in the shell.
Pasting aaaaaaaaaaaaaaaaabbbbbbbbbbbbb bbbbbbbbbbbbcccccccccccccccccccc will put the following into the shell:
aaaaaaaaaaaaaaaabbbbbbbbbbbcccccccccccccccccccc

Expected results

The text in the clipboard should be pasted without randomly dropping characters.

@speedofsound99
Copy link

same issue here
copy/paste suddenly broken, was fine last week
not 100% sure but I'd say this started after new windows feature update 1803

@brusch
Copy link
Author

brusch commented May 3, 2018

@speedofsound99 yep, seems so
Btw. only happens within ConEmu other terminals are fine.

@Werelds
Copy link

Werelds commented May 3, 2018

It is definitely related to 1803, I'm experiencing this as well, immediately after the update.

It's also 100% related to spaces. I can paste thousands of characters just fine as long as there's no space - but pasting 1 2 doesn't work 😂

Further information:

  • Running wsl.exe directly (WIN+R) works fine
  • cmd.exe via ConEmu also works fine
  • Running wsl.exe after starting cmd.exe via ConEmu also works

It only happens when running WSL directly through ConEmu.

@Maximus5
Copy link
Owner

Maximus5 commented May 3, 2018

I've said many many times. Don't run bash.exe or wsl.exe directly.
Use predefined {bash} task instead.
What shall I do to make this clear?

https://conemu.github.io/en/BashOnWindows.html

@Maximus5 Maximus5 closed this as completed May 3, 2018
@Maximus5
Copy link
Owner

Maximus5 commented May 3, 2018

Btw. only happens within ConEmu other terminals are fine.

I don't believe in that. What terminals?

Conhost? It is not a "terminal" at all. It is Windows Kernel. Of course it has privileges.
wsltty? It uses wslbridge. And you don't use wslbridge in ConEmu. Is the comparison fair?

@Werelds
Copy link

Werelds commented May 3, 2018

Well, up until 1803 there was no problem with it. All I/O worked just fine. The default {bash} task wouldn't do for me because, well, I don't use bash. I use ZSH and I'm guessing most of us who've replaced the default task with a direct call to WSL did it for that reason. bash.exe loads just that: bash. wsl.exe loads the way you'd expect a terminal emulator to load on any UNIX system, namely that it loads whatever shell you've set for your user account.

By clicking through the docs a bit I've now figured out that we can actually use ZSH through the bridge as well, by use of the -t flag on the CygWin/MSYS connector.

You may want to update the FAQ for Bash on Windows by mentioning that one can control which shell is loaded through that flag, because it's not exactly clear. You have to go into the connector docs to find that out. That should help with the repeated queries about this.

@Werelds
Copy link

Werelds commented May 3, 2018

Looks like the next version of wslbridge will do this correctly and not force bash by default. At which point I'd suggest your connector to also no longer default to -t bash.

@Maximus5
Copy link
Owner

Maximus5 commented May 3, 2018

Well, up until 1803 there was no problem with it. All I/O worked just fine.

It is not true. As mentioned in gh-1314 there were problem with IO, there were dropped or even defective characters on paste. The issue was repored on bare wsl/bash without connector too. And it was closed coz the only workaround is using connector.

@Werelds
Copy link

Werelds commented May 3, 2018

Be that as it may, for the past 6-7 months or so (that's when I switched back to Windows from my Mac) I've been using ConEmu with it set up to launch wsl.exe (so not bash.exe) directly and I haven't experienced any lost characters in pastes or anything. I'm sure some things wouldn't have worked that I simply haven't tried, but pasting wasn't one of them. The only "issue" I had with pasting was that newlines would be duplicated, but that's hardly a problem.

Perhaps something changed shortly after the mentioned issue's date and I stepped in at just the right time? I don't know what else would explain it.

At any rate, you're right, the default task does let me paste as normal now, so for the time being I'll run it with -t zsh -l. With version 0.2.5 of wslbridge it'll get rid of the bash default though and I think you should then follow their lead and either change the default bash task to leave it up to WSL or perhaps add a new default task {wsl}?

But that's food for another day (and GH PR/issue) when 0.2.5 is out :P

And just for reference for everyone else: this is how I'm starting my shell now, which is with zsh rather than bash:

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -t zsh -l

It's ever so slightly modified from the default, barely any difference.

@Maximus5
Copy link
Owner

Maximus5 commented May 3, 2018

Anyway, I found what was changed in Win10 and fix is coming.

@brusch
Copy link
Author

brusch commented May 4, 2018

@Maximus5 Thanks a lot for the fast fix - works great!

@mloskot
Copy link

mloskot commented May 22, 2018

@Maximus5

I've said many many times. Don't run bash.exe or wsl.exe directly.
Use predefined {bash} task instead.
What shall I do to make this clear?
https://conemu.github.io/en/BashOnWindows.html

Although I perfectly understand the annoyance, with all respect, is there any way to use the bridge and run [multiple distros]( instead of the default automatically selected wsl.exe (ie. without wslconfig /setdefault <my preferred distro> prior using the bridge, https://docs.microsoft.com/en-us/windows/wsl/wsl-config).

For example, I like to have multiple tasks defined one per each distro: Ubuntu, Ubuntu 18.04, Debian, Kali.
I often run multiple distros concurrently, one per tab.

@Maximus5
Copy link
Owner

@mloskot Why do you ask in this issue? It's about paste only.
Distros were discussed and explained here: #1309 (comment)

@mloskot
Copy link

mloskot commented May 22, 2018

@Maximus5 Because I'm 'suffering' of the same broken paste issue and I can not switch to the WSL bridge due to the reasons I explained (or I don't know how to get both, working paste and multi-distro working). Plus, there is this inevitable process of discovering due to the nature of the problem that does not guarantee I will find all the relevant GH issues and in the right sequence.
However, I will learn about the #1309 which I had not been aware of, thanks.

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

No branches or pull requests

5 participants