public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mark Geisert <mark@maxrnd.com>
To: The Cygwin Mailing List <cygwin@cygwin.com>
Subject: Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-8 (Test)
Date: Tue, 23 Nov 2021 01:08:01 -0800	[thread overview]
Message-ID: <5bda8193-b333-482e-6a19-3d48d5d6fe49@maxrnd.com> (raw)
In-Reply-To: <f8015fd7-adc2-88c3-7ccb-d52ecb5d0e4c@dronecode.org.uk>

Jon Turney wrote:
> On 21/11/2021 10:36, Mark Geisert wrote:
>> Hi Denis,
>>
>> Denis Excoffier wrote:
>>> Hello,
>>>
>>>> On 2021-11-03 10:59, Mark Geisert wrote:
>>>>
>>>> The following packages have been uploaded to the Cygwin distribution:
>>>>
>>>> * cygutils-1.4.16-8
>>>> * cygutils-extra-1.4.16-8
>>>> * cygutils-x11-1.4.16-8
>>>
>>>
>>> The '-u' or '-d' option of getclip does not seem to work properly under xterm.
>>> How to reproduce:
>>> 1) Open an xterm
>>> 2) Select a simple piece of text (with no line ending)
>>> 3) getclip -u
>>> 4) Observe 'Segmentation fault(core dumped)'
>>>
>>> If step 2 is replaced by ‘printf AAAA | putclip', no error.
>>> If step 3 is replaced by ‘getclip’, no error.
>>>
>>> I can’t tell whether this is new or not.
>>
>> It appears to be old.  An xterm selection is placed on the Windows clipboard in 
>> CF_UNICODETEXT format.  'getclip' can deal with this, 'getclip -u' and 'getclip 
>> -d' cannot; they always request CF_TEXT (i.e., ANSI) format and assume they get 
>> a buffer of data.  But the formats don't match and there's no data supplied.  
>> That's why the segfault occurs.
> 
> Odd... I think that Windows should convert CF_UNICODETEXT to CF_TEXT if needed
> 
> See 
> https://docs.microsoft.com/en-gb/windows/win32/dataxchg/clipboard-formats#synthesized-clipboard-formats 

I did notice that doc when I was updating getclip and putclip.  I wondered why 
that conversion didn't seem to be happening in the testcases and whether that was 
a Windows change over time.  I had no answer.

What surprised me about the segfault was that GetClipboardData(CF_TEXT) was 
returning zero, the error indication, but a subsequent GetLastError() returned 
zero as well, so no specific error.

..mark

      parent reply	other threads:[~2021-11-23  9:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03  9:59 Mark Geisert
2021-11-03 13:04 ` Takashi Yano
2021-11-04  4:31   ` Mark Geisert
2021-11-04  4:58     ` Thomas Wolff
2021-11-04  8:47       ` Mark Geisert
2021-11-04 20:08         ` Brian Inglis
2021-11-05  3:20   ` Takashi Yano
2021-11-05  5:40     ` Mark Geisert
2021-11-05  8:06       ` Takashi Yano
2021-11-05  8:53         ` Mark Geisert
2021-11-14 17:23 ` Denis Excoffier
2021-11-14 17:55   ` Mark Geisert
2021-11-14 17:55   ` Brian Inglis
2021-11-21 10:36   ` Mark Geisert
2021-11-21 14:51     ` Jon Turney
2021-11-22  7:08       ` Andrey Repin
2021-11-22  8:14       ` Takashi Yano
2021-11-23  9:08       ` Mark Geisert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5bda8193-b333-482e-6a19-3d48d5d6fe49@maxrnd.com \
    --to=mark@maxrnd.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).