[ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Mark Geisert]

The following packages have been uploaded to the Cygwin distribution:

* cygutils-1.4.16-7
* cygutils-extra-1.4.16-7
* cygutils-x11-1.4.16-7

This update fixes an issue with readshortcut in which "buffer overflow
detected" is displayed when reading most any shortcut (.lnk) file.

Thanks to Keith Christian for the bug report and simple testcase.
Enjoy!

..mark

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

Hi Mark,

Sometimes, putclip shows error
"Unable to open the clipboard"
when I run 'echo A | putclip'.

I digged into this problem, and found OpenClipboard() sometimes
fails with error ERROR_ACCESS_DENIED if it is called just after
SetClipboardData() and CloseClipboard().

Currently, putclip calls OpenClipboard()/CloseClipboard() four
times. Is there any reason why closing and reopening clipboard
several times?

Is there any problem if you open clipboard once and close it at
the end of function int putclip() just like the patch attached?

The problem above disappears if the patch is applied.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: putclip.patch --]
[-- Type: application/octet-stream, Size: 5340 bytes --]

--- a/src/cygwin-cygutils/src/clip/putclip.c
+++ b/src/cygwin-cygutils/src/clip/putclip.c
@@ -401,19 +401,6 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
       const char *CYGWIN_NATIVE = "CYGWIN_NATIVE_CLIPBOARD";
       UINT cygnativeformat;
 
-      if (!OpenClipboard (0))
-        {
-          fprintf (stderr, "Unable to open the clipboard\n");
-#if DEBUGGING
-          DWORD err = GetLastError ();
-          /* look up error code displayed here in w32api/winerror.h */
-          fprintf (stderr, "OpenClipboard returns %ld\n", err);
-#endif
-          return (PUTCLIP_ERR);
-        }
-      cygnativeformat = RegisterClipboardFormat (CYGWIN_NATIVE);
-      CloseClipboard ();
-
       // if flags.endl_mode == ENDLMODE_NOCONV 
       convbuf = buf;
       convlen = len;
@@ -541,6 +528,8 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
             free (convbuf);
           return (PUTCLIP_ERR);
         }
+      cygnativeformat = RegisterClipboardFormat (CYGWIN_NATIVE);
+
       if (cygNewFormat)
 	hData = GlobalAlloc (GMEM_MOVEABLE, convlen + sizeof (cygcb_t));
       else
@@ -551,12 +540,14 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
           fprintf (f, "Couldn't allocate global buffer for write.\n");
           if (convbuf)
             free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
       if (!(clipbuf = (void *) GlobalLock (hData)))
         {
           fprintf (f, "Couldn't lock global buffer.\n");
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
 
@@ -585,15 +576,16 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
           fprintf (stderr, "SetClipboardData returns %ld\n", err);
 #endif
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
-      CloseClipboard ();
 #if 0 // Per MSDN, don't GlobalFree a handle successfully transferred to system
       if (GlobalFree (hData))
         {
           fprintf (f,
                    "Couldn't free global buffer after write to clipboard.\n");
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
 #endif
@@ -601,27 +593,18 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
       clipbuf = NULL;
 
       /* CF_UNICODETEXT format */
-      if (!OpenClipboard (0))
-        {
-          fprintf (f, "Unable to open the clipboard\n");
-#if DEBUGGING
-          DWORD err = GetLastError ();
-          /* look up error code displayed here in w32api/winerror.h */
-          fprintf (stderr, "OpenClipboard returns %ld\n", err);
-#endif
-          free (convbuf);
-          return (PUTCLIP_ERR);
-        }
       if (!(hData = GlobalAlloc (GMEM_MOVEABLE, sizeof (WCHAR) * convlen + 2)))
         {
           fprintf (f, "Couldn't allocate global buffer for write.\n");
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
       if (!(clipbuf = (void *) GlobalLock (hData)))
         {
           fprintf (f, "Couldn't lock global buffer.\n");
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
 
@@ -655,13 +638,13 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
           free (convbuf);
           return (PUTCLIP_ERR);
         }
-      CloseClipboard ();
 #if 0 // Per MSDN, don't GlobalFree a handle successfully transferred to system
       if (GlobalFree (hData))
         {
           fprintf (f,
                    "Couldn't free global buffer after write to clipboard.\n");
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
 #endif
@@ -669,27 +652,18 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
       clipbuf = NULL;
 
       /* CF_TEXT format */
-      if (!OpenClipboard (0))
-        {
-          fprintf (f, "Unable to open the clipboard\n");
-#if DEBUGGING
-          DWORD err = GetLastError ();
-          /* look up error code displayed here in w32api/winerror.h */
-          fprintf (stderr, "OpenClipboard returns %ld\n", err);
-#endif
-          free (convbuf);
-          return (PUTCLIP_ERR);
-        }
       if (!(hData = GlobalAlloc (GMEM_MOVEABLE, convlen + 2)))
         {
           fprintf (f, "Couldn't allocate global buffer for write.\n");
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
       if (!(clipbuf = (void *) GlobalLock (hData)))
         {
           fprintf (f, "Couldn't lock global buffer.\n");
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
 
@@ -707,6 +681,7 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
           fprintf (stderr, "SetClipboardData returns %ld\n", err);
 #endif
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
       CloseClipboard ();
@@ -716,6 +691,7 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
           fprintf (f,
                    "Couldn't free global buffer after write to clipboard.\n");
           free (convbuf);
+          CloseClipboard ();
           return (PUTCLIP_ERR);
         }
 #endif

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

On Sat, 25 Sep 2021 13:31:25 +0900
Takashi Yano wrote:
> Hi Mark,
> 
> Sometimes, putclip shows error
> "Unable to open the clipboard"
> when I run 'echo A | putclip'.
> 
> I digged into this problem, and found OpenClipboard() sometimes
> fails with error ERROR_ACCESS_DENIED if it is called just after
> SetClipboardData() and CloseClipboard().
> 
> Currently, putclip calls OpenClipboard()/CloseClipboard() four
> times. Is there any reason why closing and reopening clipboard
> several times?
> 
> Is there any problem if you open clipboard once and close it at
> the end of function int putclip() just like the patch attached?
> 
> The problem above disappears if the patch is applied.

I noticed that putclip/getclip have another problem.

These utils assume the charset is always UTF-8, however, cygwin
supports locales which charset is not UTF-8 (such as CP932, EUC-JP,
CP850, CP1251, etc.).

Therefore, what abount using mbstowcs/wcstombs rather than
MultiByteToWideChar/WideCharToMultiByte like the patch attached?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: clip-charset.patch --]
[-- Type: application/octet-stream, Size: 3207 bytes --]

diff --git a/src/cygwin-cygutils/src/clip/getclip.c b/src/cygwin-cygutils/src/clip/getclip.c
index 82e7070..772dfe5 100644
--- a/src/cygwin-cygutils/src/clip/getclip.c
+++ b/src/cygwin-cygutils/src/clip/getclip.c
@@ -32,6 +32,7 @@
 #include <wchar.h>
 #include <sys/cygwin.h>
 #include <w32api/stringapiset.h>
+#include <locale.h>
 
 #define DEBUGGING 0 // Set 1 to display debug output on stderr
 
@@ -198,6 +199,8 @@ main (int argc, const char **argv)
       goto exit;
     }
   rest = poptGetArgs (optCon);
+
+  setlocale (LC_ALL, "");
   if (rest == NULL)
     ec |= getclip (stdout, flags, stderr, program_name);
   else
@@ -425,16 +428,14 @@ getclip (FILE * out, flags_struct flags, FILE * f, char *name)
               int srclen = wcslen (lpwstr); // wide-char count
               int dstlen = srclen << 2; // byte count
               LPSTR dst = (LPSTR) malloc (dstlen);
-              int res = WideCharToMultiByte (CP_UTF8, 0, lpwstr, srclen,
-                                             dst, dstlen, NULL, NULL);
+              int res = wcstombs (dst, lpwstr, dstlen);
               if (res > 0)
                 fwrite (dst, sizeof (char), res, out);
-              else if (res == 0)
+              else if (res == -1)
                 {
 #if DEBUGGING
-                  DWORD err = GetLastError ();
-                  /* look up error code displayed here in w32api/winerror.h */
-                  fprintf (stderr, "WideCharToMultiByte returns %ld\n", err);
+                  /* look up error code displayed here in sys/errno.h */
+                  fprintf (stderr, "wcstombs error (errno=%d)\n", errno);
 #endif
                 }
               free (dst);
diff --git a/src/cygwin-cygutils/src/clip/putclip.c b/src/cygwin-cygutils/src/clip/putclip.c
index abdb8cf..ae58b62 100644
--- a/src/cygwin-cygutils/src/clip/putclip.c
+++ b/src/cygwin-cygutils/src/clip/putclip.c
@@ -32,6 +32,7 @@
 #include <wchar.h>
 #include <sys/cygwin.h>
 #include <w32api/stringapiset.h>
+#include <locale.h>
 
 #define DEBUGGING 0 // Set 1 to display debug output on stderr
 
@@ -198,6 +199,7 @@ main (int argc, const char **argv)
 
   rest = poptGetArgs (optCon);
 
+  setlocale (LC_ALL, "");
   if (rest == NULL)
     ec |= putclip (stdin, flags, stderr, program_name);
   else
@@ -608,17 +610,16 @@ putclip (FILE * in, flags_struct flags, FILE * f, char *name)
           return (PUTCLIP_ERR);
         }
 
-      int res = MultiByteToWideChar (CP_UTF8, 0, convbuf, convlen,
-                                     (LPWSTR) clipbuf, convlen + 1);
-      if (res == 0)
+      convbuf[convlen] = '\0';
+      int res = mbstowcs (clipbuf, convbuf, convlen + 1);
+      if (res == -1)
         {
 #if DEBUGGING
-          DWORD err = GetLastError ();
-          /* look up error code displayed here in w32api/winerror.h */
-          fprintf (stderr, "MultiByteToWideChar returns %ld\n", err);
+          /* look up error code displayed here in sys/errno.h */
+          fprintf (stderr, "mbstowcs error (errno=%d)\n", errno);
 #endif
         }
-      else /* res != 0 */
+      else /* res != -1 */
         {
           *((WCHAR *) clipbuf + res) = 0; /* NULL-terminate just in case */
 #if DEBUGGING

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Takashi Yano]

On Sat, 25 Sep 2021 16:23:54 +0900
Takashi Yano wrote:
@@ -32,6 +32,6 @@
>  #include <wchar.h>
>  #include <sys/cygwin.h>
>  #include <w32api/stringapiset.h>
> +#include <locale.h>
>  
>  #define DEBUGGING 0 // Set 1 to display debug output on stderr
>  

A small thing.

Including w32api/stringapiset.h is no longer necessary with
this patch.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Mark Geisert]

Hi Takashi,

Takashi Yano via Cygwin wrote:
> Sometimes, putclip shows error
> "Unable to open the clipboard"
> when I run 'echo A | putclip'.
> 
> I digged into this problem, and found OpenClipboard() sometimes
> fails with error ERROR_ACCESS_DENIED if it is called just after
> SetClipboardData() and CloseClipboard().
> 
> Currently, putclip calls OpenClipboard()/CloseClipboard() four
> times. Is there any reason why closing and reopening clipboard
> several times?

I don't know why the author coded putclip that way.  Perhaps Windows required 
different clipboard interfacing long ago?  Or the author was being very cautious?

> Is there any problem if you open clipboard once and close it at
> the end of function int putclip() just like the patch attached?
> 
> The problem above disappears if the patch is applied.

I will implement something similar to your patch for -8 in the next few days. 
Thank you for digging into this issue; I had seen evidence the clipboard was busy 
but wondered why Windows itself couldn't serialize access.  It's amusing to find 
that putclip is apparently interfering with itself :-).
Cheers,

..mark

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Mark Geisert]

Hi Takashi,

Takashi Yano via Cygwin wrote:
> On Sat, 25 Sep 2021 13:31:25 +0900
> Takashi Yano wrote:
[...]
> I noticed that putclip/getclip have another problem.
> 
> These utils assume the charset is always UTF-8, however, cygwin
> supports locales which charset is not UTF-8 (such as CP932, EUC-JP,
> CP850, CP1251, etc.).
> 
> Therefore, what abount using mbstowcs/wcstombs rather than
> MultiByteToWideChar/WideCharToMultiByte like the patch attached?

Oh, that's how /dev/clipboard does the translations.  I like that very much and 
will apply your patch as part of an upcoming -8 release of cygutils.

..mark

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Mark Geisert]

Takashi Yano via Cygwin wrote:
> On Sat, 25 Sep 2021 16:23:54 +0900
> Takashi Yano wrote:
> @@ -32,6 +32,6 @@
>>   #include <wchar.h>
>>   #include <sys/cygwin.h>
>>   #include <w32api/stringapiset.h>
>> +#include <locale.h>
>>   
>>   #define DEBUGGING 0 // Set 1 to display debug output on stderr
>>   
> 
> A small thing.
> 
> Including w32api/stringapiset.h is no longer necessary with
> this patch.

Noted.  Thanks again Takashi!

..mark

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Doug Henderson]

On Sun, 26 Sept 2021 at 03:41, Mark Geisert <mark@maxrnd.com> wrote:
>
> Hi Takashi,
>
> >
> > Currently, putclip calls OpenClipboard()/CloseClipboard() four
> > times. Is there any reason why closing and reopening clipboard
> > several times?
>
> I don't know why the author coded putclip that way.  Perhaps Windows required
> different clipboard interfacing long ago?  Or the author was being very cautious?
>
> > Is there any problem if you open clipboard once and close it at
> > the end of function int putclip() just like the patch attached?
> >
> > The problem above disappears if the patch is applied.

Does the code save the clipping to the clipboard with multiple
formats? e.g. an ascii format, a utf-9 and a utf-16 or even an html
version? I Don't recall how you had to code the clip operation so the
paster can choose the best format to paste. I think mintty does this
so that a text editor can paste the text from the screen, but a html
editor can paste the maked-up text with bolding, underlines, etc.

If you have turned on "Clipboard history" and/or "Sync across devices"
in the Clipboard Settings, in at least some versions of Windows 10,
there is an internet round trip to a Microsoft server that causes a
delay between the copy-to-clipboard operation and when that clip is
available for a paste-from-clipboard operation. If you perform a
Ctrl-C immediately followed by a Ctrl-V, i.e., before the round trip
completes, you will paste the previous clipboard contents instead of
the expected new content.

HTH
Doug

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Westcoast Human]

I'm just going to jump in here and report what I think is an issue I
am having with 'putclip.'

For years I've been using a Windows shortcut to execute a simple
filter function. It has recently stopped working. This is the 'target'
entry for the shortcut:
C:\Windows\System32\cmd.exe /c "c:\cygwin64\bin\getclip.exe |
c:\cygwin64\bin\tr.exe -s '\012\015' ' ' |
c:\cygwin64\bin\putclip.exe"

This now wedges and is not interruptible with Ctrl-C, but closing the
CMD window kills everything. Task Manager shows that putclip is
apparently stuck in a loop waiting for something to happen as the
counts in "I/O Other" and "I/O Other bytes" keep increasing at a
regular rate (should a timeout error be incorporated, perhaps?)

I can use Task Manager to generate a Windows dump file, if that helps.

I have extensive embedded systems programming experience, but know
next to nothing about the internals of Windows or Cygwin.

Windows 10.

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Brian Inglis]

On 2021-09-26 18:46, Westcoast Human via Cygwin wrote:
> I'm just going to jump in here and report what I think is an issue I
> am having with 'putclip.'
> 
> For years I've been using a Windows shortcut to execute a simple
> filter function. It has recently stopped working. This is the 'target'
> entry for the shortcut:
> C:\Windows\System32\cmd.exe /c "c:\cygwin64\bin\getclip.exe |
> c:\cygwin64\bin\tr.exe -s '\012\015' ' ' |
> c:\cygwin64\bin\putclip.exe"
> 
> This now wedges and is not interruptible with Ctrl-C, but closing the
> CMD window kills everything. Task Manager shows that putclip is
> apparently stuck in a loop waiting for something to happen as the
> counts in "I/O Other" and "I/O Other bytes" keep increasing at a
> regular rate (should a timeout error be incorporated, perhaps?)

Try:

c:\cygwin64\bin\dash -c '/bin/getclip | /bin/tr -s "\r\n" " " | 
/bin/putclip'

e.g.

$ mkshortcut -D -n clip-strip /bin/dash -a "-c '/bin/getclip | /bin/tr 
-s \"\r\n\" \" \" | /bin/putclip'"

works and doesn't hang with latest Cygwin.

Note: tr has accepted C escapes for decades (Turbo C days), and use of 
"\012\015" == "\n\r" is anachronistic, rarely encountered compared to 
older systems' and network protocols' text line ending "\r\n", where 
both may be repeated, or only the "\n" for skipping lines.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Brian Inglis]

On 2021-09-27 00:13, Brian Inglis wrote:
> On 2021-09-26 18:46, Westcoast Human wrote:
>> I'm just going to jump in here and report what I think is an issue I
>> am having with 'putclip.'
>>
>> For years I've been using a Windows shortcut to execute a simple
>> filter function. It has recently stopped working. This is the 'target'
>> entry for the shortcut:
>> C:\Windows\System32\cmd.exe /c "c:\cygwin64\bin\getclip.exe |
>> c:\cygwin64\bin\tr.exe -s '\012\015' ' ' |
>> c:\cygwin64\bin\putclip.exe"
>>
>> This now wedges and is not interruptible with Ctrl-C, but closing the
>> CMD window kills everything. Task Manager shows that putclip is
>> apparently stuck in a loop waiting for something to happen as the
>> counts in "I/O Other" and "I/O Other bytes" keep increasing at a
>> regular rate (should a timeout error be incorporated, perhaps?)

> $ mkshortcut -D -n clip-strip /bin/dash -a "-c '/bin/getclip | /bin/tr 
> -s \"\r\n\" \" \" | /bin/putclip'"

Sorry, missed out minimize window:

$ mkshortcut -D -s min -n clip-strip /bin/dash -a "-c '/bin/getclip | 
/bin/tr -s \"\r\n\" \" \" | /bin/putclip'"

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Takashi Yano]

On Sun, 26 Sep 2021 17:46:16 -0700
Westcoast Human wrote:
> I'm just going to jump in here and report what I think is an issue I
> am having with 'putclip.'
> 
> For years I've been using a Windows shortcut to execute a simple
> filter function. It has recently stopped working. This is the 'target'
> entry for the shortcut:
> C:\Windows\System32\cmd.exe /c "c:\cygwin64\bin\getclip.exe |
> c:\cygwin64\bin\tr.exe -s '\012\015' ' ' |
> c:\cygwin64\bin\putclip.exe"
> 
> This now wedges and is not interruptible with Ctrl-C, but closing the
> CMD window kills everything. Task Manager shows that putclip is
> apparently stuck in a loop waiting for something to happen as the
> counts in "I/O Other" and "I/O Other bytes" keep increasing at a
> regular rate (should a timeout error be incorporated, perhaps?)

Could you please try
cygwin 3.3.0-0.2.6c1f49f83fde (TEST)
https://cygwin.com/pipermail/cygwin/2021-September/249475.html
?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Takashi Yano]

On Mon, 27 Sep 2021 19:10:18 +0900
Takashi Yano wrote:
> On Sun, 26 Sep 2021 17:46:16 -0700
> Westcoast Human wrote:
> > I'm just going to jump in here and report what I think is an issue I
> > am having with 'putclip.'
> > 
> > For years I've been using a Windows shortcut to execute a simple
> > filter function. It has recently stopped working. This is the 'target'
> > entry for the shortcut:
> > C:\Windows\System32\cmd.exe /c "c:\cygwin64\bin\getclip.exe |
> > c:\cygwin64\bin\tr.exe -s '\012\015' ' ' |
> > c:\cygwin64\bin\putclip.exe"
> > 
> > This now wedges and is not interruptible with Ctrl-C, but closing the
> > CMD window kills everything. Task Manager shows that putclip is
> > apparently stuck in a loop waiting for something to happen as the
> > counts in "I/O Other" and "I/O Other bytes" keep increasing at a
> > regular rate (should a timeout error be incorporated, perhaps?)
> 
> Could you please try
> cygwin 3.3.0-0.2.6c1f49f83fde (TEST)
> https://cygwin.com/pipermail/cygwin/2021-September/249475.html
> ?

This problem seems to be a problem of cygwin 3.2.0 which was
already fixed in git head by:

commit b4fc81edcc25b5c313ab3805dc0bcd015c370e62
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Mon Apr 19 19:30:45 2021 +0900

    Cygwin: console: Fix race issue regarding cons_master_thread().

    - With this patch, the race issue regarding starting/stopping
      cons_master_thread() introduced by commit ff4440fc is fixed.

      Addresses:
        https://cygwin.com/pipermail/cygwin/2021-April/248292.html

Thanks.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Richard Beels]

On 2021-09-26 18:46, Westcoast Human via Cygwin wrote:
><snipped>
>
>This now wedges and is not interruptible with Ctrl-C, but closing the
>CMD window kills everything. Task Manager shows that putclip is
>apparently stuck in a loop waiting for something to happen as the
>counts in "I/O Other" and "I/O Other bytes" keep increasing at a
>regular rate (should a timeout error be incorporated, perhaps?)

You don't need to kill the whole terminal session, open up another 
one and kill the rogue putclip with kill(1) or pskill (from 
systernals).  Could even use procexp (from systernals) without having 
to open a new term.

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Richard Beels]

On 2021-09-26 18:46, Westcoast Human via Cygwin wrote:
><snipped>
>
>This now wedges and is not interruptible with Ctrl-C, but closing the
>CMD window kills everything. Task Manager shows that putclip is
>apparently stuck in a loop waiting for something to happen as the
>counts in "I/O Other" and "I/O Other bytes" keep increasing at a
>regular rate (should a timeout error be incorporated, perhaps?)

You don't need to kill the whole terminal session, open up another 
one and kill the rogue putclip with kill(1) or pskill (from 
systernals).  Could even use procexp (from systernals) without having 
to open a new term.

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Richard Beels]

On 2021-09-26 18:46, Westcoast Human via Cygwin wrote:
><snipped>
>
>This now wedges and is not interruptible with Ctrl-C, but closing the
>CMD window kills everything. Task Manager shows that putclip is
>apparently stuck in a loop waiting for something to happen as the
>counts in "I/O Other" and "I/O Other bytes" keep increasing at a
>regular rate (should a timeout error be incorporated, perhaps?)

You don't need to kill the whole terminal session, open up another 
one and kill the rogue putclip with kill(1) or pskill (from 
systernals).  Could even use procexp (from systernals) without having 
to open a new term.

Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7

[Westcoast Human]

On Mon, Sep 27, 2021 at 4:07 AM Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
>
> On Mon, 27 Sep 2021 19:10:18 +0900
> Takashi Yano wrote:
> > On Sun, 26 Sep 2021 17:46:16 -0700
> > Westcoast Human wrote:
> > > I'm just going to jump in here and report what I think is an issue I
> > > am having with 'putclip.'
> > >
> > > For years I've been using a Windows shortcut to execute a simple
> > > filter function. It has recently stopped working. This is the 'target'
> > > entry for the shortcut:
> > > C:\Windows\System32\cmd.exe /c "c:\cygwin64\bin\getclip.exe |
> > > c:\cygwin64\bin\tr.exe -s '\012\015' ' ' |
> > > c:\cygwin64\bin\putclip.exe"
> > >
> > > This now wedges and is not interruptible with Ctrl-C, but closing the
> > > CMD window kills everything. Task Manager shows that putclip is
> > > apparently stuck in a loop waiting for something to happen as the
> > > counts in "I/O Other" and "I/O Other bytes" keep increasing at a
> > > regular rate (should a timeout error be incorporated, perhaps?)
> >
> > Could you please try
> > cygwin 3.3.0-0.2.6c1f49f83fde (TEST)

I tried this and it appears to work fine now.