* [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 @ 2021-09-23 6:37 Mark Geisert 2021-09-25 4:31 ` Takashi Yano 0 siblings, 1 reply; 17+ messages in thread From: Mark Geisert @ 2021-09-23 6:37 UTC (permalink / raw) To: cygwin; +Cc: 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-23 6:37 [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 Mark Geisert @ 2021-09-25 4:31 ` Takashi Yano 2021-09-25 7:23 ` Takashi Yano 2021-09-26 9:40 ` Mark Geisert 0 siblings, 2 replies; 17+ messages in thread From: Takashi Yano @ 2021-09-25 4:31 UTC (permalink / raw) To: cygwin [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-25 4:31 ` Takashi Yano @ 2021-09-25 7:23 ` Takashi Yano 2021-09-25 8:12 ` Takashi Yano 2021-09-26 9:43 ` Mark Geisert 2021-09-26 9:40 ` Mark Geisert 1 sibling, 2 replies; 17+ messages in thread From: Takashi Yano @ 2021-09-25 7:23 UTC (permalink / raw) To: cygwin [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-25 7:23 ` Takashi Yano @ 2021-09-25 8:12 ` Takashi Yano 2021-09-26 9:44 ` Mark Geisert 2021-09-26 9:43 ` Mark Geisert 1 sibling, 1 reply; 17+ messages in thread From: Takashi Yano @ 2021-09-25 8:12 UTC (permalink / raw) To: cygwin 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-25 8:12 ` Takashi Yano @ 2021-09-26 9:44 ` Mark Geisert 0 siblings, 0 replies; 17+ messages in thread From: Mark Geisert @ 2021-09-26 9:44 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-25 7:23 ` Takashi Yano 2021-09-25 8:12 ` Takashi Yano @ 2021-09-26 9:43 ` Mark Geisert 1 sibling, 0 replies; 17+ messages in thread From: Mark Geisert @ 2021-09-26 9:43 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-25 4:31 ` Takashi Yano 2021-09-25 7:23 ` Takashi Yano @ 2021-09-26 9:40 ` Mark Geisert 2021-09-26 18:41 ` Doug Henderson 1 sibling, 1 reply; 17+ messages in thread From: Mark Geisert @ 2021-09-26 9:40 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-26 9:40 ` Mark Geisert @ 2021-09-26 18:41 ` Doug Henderson 2021-09-27 0:46 ` Westcoast Human 0 siblings, 1 reply; 17+ messages in thread From: Doug Henderson @ 2021-09-26 18:41 UTC (permalink / raw) To: Mark Geisert; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-26 18:41 ` Doug Henderson @ 2021-09-27 0:46 ` Westcoast Human 2021-09-27 6:13 ` Brian Inglis 2021-09-27 10:10 ` Takashi Yano 0 siblings, 2 replies; 17+ messages in thread From: Westcoast Human @ 2021-09-27 0:46 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-27 0:46 ` Westcoast Human @ 2021-09-27 6:13 ` Brian Inglis 2021-09-27 6:29 ` Brian Inglis ` (3 more replies) 2021-09-27 10:10 ` Takashi Yano 1 sibling, 4 replies; 17+ messages in thread From: Brian Inglis @ 2021-09-27 6:13 UTC (permalink / raw) To: cygwin 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.] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-27 6:13 ` Brian Inglis @ 2021-09-27 6:29 ` Brian Inglis 2021-09-27 20:00 ` Richard Beels ` (2 subsequent siblings) 3 siblings, 0 replies; 17+ messages in thread From: Brian Inglis @ 2021-09-27 6:29 UTC (permalink / raw) To: cygwin 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.] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-27 6:13 ` Brian Inglis 2021-09-27 6:29 ` Brian Inglis @ 2021-09-27 20:00 ` Richard Beels 2021-09-27 20:00 ` Richard Beels 2021-09-27 20:00 ` Richard Beels 3 siblings, 0 replies; 17+ messages in thread From: Richard Beels @ 2021-09-27 20:00 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-27 6:13 ` Brian Inglis 2021-09-27 6:29 ` Brian Inglis 2021-09-27 20:00 ` Richard Beels @ 2021-09-27 20:00 ` Richard Beels 2021-09-27 20:00 ` Richard Beels 3 siblings, 0 replies; 17+ messages in thread From: Richard Beels @ 2021-09-27 20:00 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-27 6:13 ` Brian Inglis ` (2 preceding siblings ...) 2021-09-27 20:00 ` Richard Beels @ 2021-09-27 20:00 ` Richard Beels 3 siblings, 0 replies; 17+ messages in thread From: Richard Beels @ 2021-09-27 20:00 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-27 0:46 ` Westcoast Human 2021-09-27 6:13 ` Brian Inglis @ 2021-09-27 10:10 ` Takashi Yano 2021-09-27 11:07 ` Takashi Yano 1 sibling, 1 reply; 17+ messages in thread From: Takashi Yano @ 2021-09-27 10:10 UTC (permalink / raw) To: cygwin; +Cc: Westcoast Human 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-27 10:10 ` Takashi Yano @ 2021-09-27 11:07 ` Takashi Yano 2021-09-28 3:58 ` Westcoast Human 0 siblings, 1 reply; 17+ messages in thread From: Takashi Yano @ 2021-09-27 11:07 UTC (permalink / raw) To: cygwin; +Cc: Westcoast Human 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 2021-09-27 11:07 ` Takashi Yano @ 2021-09-28 3:58 ` Westcoast Human 0 siblings, 0 replies; 17+ messages in thread From: Westcoast Human @ 2021-09-28 3:58 UTC (permalink / raw) To: Takashi Yano; +Cc: cygwin 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-09-28 3:58 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-23 6:37 [ANNOUNCEMENT] Updated: cygutils 1.4.16-7 Mark Geisert 2021-09-25 4:31 ` Takashi Yano 2021-09-25 7:23 ` Takashi Yano 2021-09-25 8:12 ` Takashi Yano 2021-09-26 9:44 ` Mark Geisert 2021-09-26 9:43 ` Mark Geisert 2021-09-26 9:40 ` Mark Geisert 2021-09-26 18:41 ` Doug Henderson 2021-09-27 0:46 ` Westcoast Human 2021-09-27 6:13 ` Brian Inglis 2021-09-27 6:29 ` Brian Inglis 2021-09-27 20:00 ` Richard Beels 2021-09-27 20:00 ` Richard Beels 2021-09-27 20:00 ` Richard Beels 2021-09-27 10:10 ` Takashi Yano 2021-09-27 11:07 ` Takashi Yano 2021-09-28 3:58 ` Westcoast Human
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).