On Aug 9 05:53, Andy Koppe wrote: > On 8 August 2013 17:07, Ryan Johnson wrote: > > On 08/08/2013 11:48 AM, Corinna Vinschen wrote: > >> > >> On Aug 8 17:32, Corinna Vinschen wrote: > >>> > >>> On Aug 8 09:48, Ryan Johnson wrote: > >>>> > >>>> Hi all, > >>>> > >>>> (no, that's not a typo in the subject line) > >>>> > >>>> 64-bit install, bash inside mintty, all latest packages with the > >>>> cygwin1.dll snapshot shown below... > >>>> > >>>> # <<< --- begin STC --->>> > >>>> $ uname -a > >>>> CYGWIN_NT-6.1 ryan-laptop-v02 1.7.23s(0.268/5/3) 20130729 19:11:42 > >>>> x86_64 Cygwin > >>>> > >>>> $ echo "Reading" > /dev/clipboard > >>>> > >>>> # hit [shift]+[insert] to paste > >>>> # (hopefully 8 characters is not "too long" to paste into a TTY) > >>>> # then hit ^D to finish > >>>> $ cat > tmp.txt > >>>> > >>>> $ cat tmp.txt > >>>> Rg > >>>> eRaedaidnign > >>>> g > >>> > >>> The only idea I have is this. The clipboard data is stored as > >>> CF_UNICODETEXT and as the Cygwin-private CYGWIN_NATIVE_CLIPBOARD format. > >>> How's shift-insert implemented in mintty? If it reads the CF_UNICODETEXT > >>> part and sends it to the pty unchanged, that could explain > >>> this behaviour. > >> > >> The pty already gets 16 chars. And pasting the text into CMD or, FWIW, > >> any Windows console window works as expected. So this looks like a > >> mintty bug right now. > > > > That's what I thought at first, too, but it pastes fine directly into the > > terminal... and then I had a brain cramp and didn't add that to the STC: > > > > $ echo reading > /dev/clipboard > > # press [shift]+[insert] here... > > $ echo > > reading > > > > Still a mintty bug? > > Don't think so. Mintty has no idea what it's pasting to; it just > writes the clipboard content to the pty (which it obtains from > CF_UNICODETEXT and converts to the current charset). > > I couldn't reproduce the problem with 1.7.22, but I could with the > 20130729 snapshot. With 1.7.22, when you paste during the 'cat > >tmp.txt', the text is correctly echoed back to the terminal and put > into the file. With the snapshot, it looks like the actual input and > the echo both end up in the file.
The snapshot date should have been a fairly good hint, but I missed it nevertheless. The problem is an accidental checkin which was reverted on 2013-07-31. Consequentially, if you would update to the 2013-07-31 snapshot, the problem should go away... with the tiny downside that we neglected to upload a 64 bit snapshot on 2013-07-31. Duh. I'm going to release 1.7.23 today anyway, so I'll not upload a new snapshot for now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
