Link/$PATH interaction problem

2021-01-23 Thread Frank Eske via Cygwin
Similar to December's "cygwin1.dll > 3.1.4 Program execution fails if (WSL-)symlink exists and is present in PATH", but it's still present in 3.1.6 and 3.1.7. While I can revert back to 3.1.4 (and 3.1.2,) links I have created since then do not show up as links and are listed as owned by

Re: xterm tab key (temporarily) locks keyboard

2020-10-21 Thread Frank Eske via Cygwin
) seems like the most likely culprit. I did create a .fonts file for experimentation which is just now removed. (It's too early to tell whether that somehow created this problem.) On Sun, Oct 18, 2020 at 2:07 PM Frank Eske wrote: > If the tab key is entered as the first character running the b

xterm tab key (temporarily) locks keyboard

2020-10-18 Thread Frank Eske via Cygwin
If the tab key is entered as the first character running the bash shell on an xterm terminal, the keyboard temporarily locks. Control-C writes ^C but doesn't unlock it. This doesn't happen on Fedora. It also doesn't lock if a space is typed first. This occurs whether or not the xterm console is

Cygwin X server accepts xfixes version 5.0 but doesn't handle xcb_xfixes_hide_cursor

2020-10-15 Thread Frank Eske via Cygwin
I'm building an XCB-based application that uses xcb_xfixes_hide_cursor. The X server reports back version 5.0 in xcb_fixes_query_version_reply and accepts xcb_xfixes_hide_cursor requests, but does not hide the cursor. When omitting the xcb_fixes_query_version operation, the xcb_xfixes_hide_cursor

openssh 8.1p1-1 performance regression

2020-01-24 Thread Frank Eske
I recently updated my Cygwin installation and ran into a strange performance problem. At least part of the problem was introduced between openssh 8.1p1-1 and 8.0p1-2. Here's one way to reproduce the problem: 1) Start Cygwin X using "xinit something -- -clipboard" File something contains at