Clipboard issue

[brechtsanders]

I have an issue with recent versions of MSYS2 that I didn't have with older versions.

I often paste a large number of commands, some of which are longer that the console width. There are also multiline commands in there (e.g. shell if stuff with the fi several lines later). But I do make sure there are no tabs in there to avoid autocompletion from kicking in.

In old MSYS2 I could just paste everything and the commands would start right away.

In newer MSYS2 after pasting it is apparently waiting for another Enter before starting.

But what's worse: the data pasted isn't intact. Sometimes pieces are missing, sometimes it gets truncated, sometimes both. I also noticed sometimes some part of the beginning of the clipboard is pasted at the end.

I have reproduced this on Windows 10 and Windows 11.

I tried running the shell via msys2.exe as well as others like mingw64.exe, and I even tried running sh.exe from ConsoleZ and from Windows Terminal in Windows 11.

I tried pasting from a different source (Notepad instead of Notepad++).

I tried changing the copied source (in Notepad++) to different line endings (CR, LF, CR+LF).

But the issue remains.

Is there some kind of setting or environment variable to get the old paste behaviour back?

[jeremyd2019]

I have diagnosed an issue like this once before and it turned out to be a new "feature" in readline and bash (https://lists.gnu.org/archive/html/info-gnu/2020-12/msg00002.html, point 2.h), called "bracketed paste". try running bind 'set enable-bracketed-paste off' in bash to test, or setting set enable-bracketed-paste off in ~/.inputrc for a more permanent setting.

[brechtsanders]

Thanks for the advice, but that doesn't solve it.

What is also strange is that it doesn't also truncate the same clipboard contents in the same place.

Do you know where the new behaviours comes from that ask for Enter to confirm after paste in certain terminals and that scroll long lines on the same line? If I know how to disable these features they can be eliminated as possible causes.

[jeremyd2019]

No, I assumed they were part of the bracketed-paste thing. It seems likely they are part of readline though.

https://tiswww.case.edu/php/chet/readline/readline.html#IDX21

enable-bracketed-paste When set to 'On', Readline will configure the terminal in a way that will enable it to insert each paste into the editing buffer as a single string of characters, instead of treating each character as if it had been read from the keyboard. This can prevent pasted characters from being interpreted as editing commands. The default is 'On'.

[brechtsanders]

If it is readline-related, which other tool could I use to paste the same text in to compare the results?

Is it important what TERM is set to? I have it set to xterm-256color

[jeremyd2019]

If it is readline-related, which other tool could I use to paste the same text in to compare the results?

Maybe try dash? Or even cat > somefile, paste, and hit Ctrl-D.

Is it important what TERM is set to? I have it set to xterm-256color

You could set it to something like dumb and that should turn off all fancy terminal features...

[brechtsanders]

Test in dash has the same issues.

Test with cat has no issues.

I did some more tests and found that running bind 'set enable-bracketed-paste off' does work, but only when using mintty. Normally I don't use mintty, but I just run bash from ConsoleZ or even in a normal terminal window. ConsoleZ allows opening many shells in one tabbed window, which I miss in mintty, and since mintty isn't a real Windows console it won't work with ConsoleZ.

[jeremyd2019]

huh, could be some bug in the cygwin/msys console code then. Maybe try setting MSYS=enable_pcon before launching any msys process, and see if that code path has any better behavior? I kind of doubt it though, I feel like the console would have been provided by the launcher (ConsoleZ or normal conhost) not the runtime.

[brechtsanders]

No improvement when launching shell with MSYS=enable_pcon set.

[jeremyd2019]

Maybe @dscho has some ideas? He's had more battles with the console code than probably anybody else here.

[dscho]

Seems as if this could be the same issue as https://github.com/GitCredentialManager/git-credential-manager/issues/576. If it is, then https://github.com/git-for-windows/git-sdk-64/blob/b66f658faf70ae7de7656c46973d3b371dea1ab4/usr/bin/msys-2.0.dll should work around the issue, and https://github.com/git-for-windows/git-sdk-64/blob/b66f658faf70ae7de7656c46973d3b371dea1ab4%5E/usr/bin/msys-2.0.dll should not.

@brechtsanders could you verify this by temporarily replacing your /usr/bin/msys-2.0.dll versions with above-linked versions?

[jeremyd2019]

is this git-for-windows/git#3936? Were the patches for that merged in this repo or only in git-for-windows's fork?

[dscho]

is this git-for-windows/git#3936?

If the msys-2.0.dll I asked @brechtsanders to try fixed the issue, then no, it isn't the same issue: The patches I integrated into Git for Windows' fork of the MSYS2 runtime were authored 12 and 9 days ago, respectively, while I asked the reporter to test some tentative fixes a mere week shy of a full six months ago.

Were the patches for that merged in this repo or only in git-for-windows's fork?

Yes, because I was not sure how long it would take Cygwin to release v3.3.6 with these fixes, and I needed to get a fix into Git for Windows in time for the v2.37.1 release. In the meantime, it looks to me as if there is still too steady a trickle of bug fixes (here and here are fixes slated for the next v3.3.x release and they have been committed only 5 days ago) to expect v3.3.6 any time soon.

@jeremyd2019 do you want to have an intermediate version ("v3.3.5 plus") in MSYS2, just like I did for Git for Windows? I can totally do that.

As far as this here ticket is concerned, I am very much in favor of closing it: the original reporter was active only on the day of the initial report and then went silent, and that's been two days shy of seven full months ago, which I find quite unreasonable an amount of time to wait for any answer.

[brechtsanders]

Sorry about the delay in response. I was forced to revert to older MSYS2 for daily operations due to this issue, as this issue slowed down my work significantly with neer versions.

I still had the issue with more recent MSYS2 releases, but haven't tried with the latest download yet.

@dscho Where exactly can I find the msys-2.0.dll you want me to try?

[dscho]

@dscho Where exactly can I find the msys-2.0.dll you want me to try?

It expired.

[brechtsanders]

Just tried again with latest msys2-base-x86_64-20220603 and large paste is still messed up.

FYI: My MSYS2 bash shell runs the following at startup to avoid features that slow down pasting:

bind 'set enable-bracketed-paste off' &> /dev/null
bind 'set horizontal-scroll-mode off' &> /dev/null

[dscho]

Try replacing your msys-2.0.dll with Git for Windows' version.

[brechtsanders]

I just replaced that DLL and it looks like large paste is still garbled...

[dscho]

@brechtsanders then try with regular Cygwin. It's possible that it's a Cygwin issue, in which case they're usually pretty quick to fix 'em.