Re: terminal control chars broken?
On 1/24/20, Eugene Klimov wrote: > Try following registry file > - > Windows Registry Editor Version 5.00 > > [HKEY_CURRENT_USER\Console] > "VirtualTerminalLevel"=dword:0001 > - Thank you! That looks much better :) > also switch to cygwin 3.0 instead of cygwin 3.1.2 could help My old machine is still on 3.0.7, so I guess that explains why I haven't run into this before Regards Lee > > пт, 24 янв. 2020 г. в 12:15, Lee >> >> New Windows 10 PC, new install of 64 bit cygwin, building tidy and the >> make progress indicator is displayed on a new line each time. >> >> Since it is a new machine/setup it's probably something I'm missing/ >> didn't install, but I have no idea what :( >> >> Any idea how to keep the progress indicator on the same line? >> >> mkdir /source >> cd /source >> mkdir tidy >> cd tidy >> git clone https://github.com/htacg/tidy-html5.git >> cd tidy-html5/build/cmake >> cmake ../.. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local >> \ >> -DBUILD_SHARED_LIB:BOOL=YES \ >> -DTIDY_RC_NUMBER=next.2020.01.24 >> make >> >> and everything looks normal until it gets to >> -- Build files have been written to: /source/tidy/tidy-html5/build/cmake >> e >> [ 1%] o >> [ 3%] >> [ 5%] o >> [ 7%] >> [ 8%] o >> [ 10%] o >> [ 12%] o >> [ 14%] o >> [ 16%] o >> [ >> 17%] o >> >> [ 19%] o >> >> [ 21%] o >> >> [ 23%] o >> >> [ 25%] o >> >> [ 26%] >> >> [ 28%] o >> >> [ 30%] >>[ 32%] o >>[ 33%] o >>[ 35%] o >>[ 37%] >>[ 39%] o >>[ 41%] o >>[ 42%] o >>[ 44%] o >>[ 46%] >> o >> >> [ 48%] l >> >> [ 48%] Built target tidy-share >> c >> [ 50%] o >> [ 51%] >> [ 53%] o >> [ 55%] o >> [ 57%] o >> [ 58%] o >> [ 60%] >>[ 62%] o >>[ 64%] >>[ >> 66%] o >> >> [ 67%] o >> >> [ 69%] o >> >> [ 71%] >> >> [ 73%] o >> >> [ 75%] o >> >> [ 76%] o >> >> [ 78%] >>[ 80%] o >>[ 82%] >> [ 83%] o >> [ 85%] o >> [ 87%] o >> [ 89%] o >> [ 91%] o >> [ 92%] >> [ 94%] >> o >> >>[ 96%] a >> >>[ 96%] Built target tidy-static >> y >> [ 98%] o >> [100%] e >> [100%] Built target tidy >> n >> l >> l >>1 >> [100%] Built target man >> -- 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
Re: terminal control chars broken?
Try following registry file - Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Console] "VirtualTerminalLevel"=dword:0001 - also switch to cygwin 3.0 instead of cygwin 3.1.2 could help пт, 24 янв. 2020 г. в 12:15, Lee : > > New Windows 10 PC, new install of 64 bit cygwin, building tidy and the > make progress indicator is displayed on a new line each time. > > Since it is a new machine/setup it's probably something I'm missing/ > didn't install, but I have no idea what :( > > Any idea how to keep the progress indicator on the same line? > > mkdir /source > cd /source > mkdir tidy > cd tidy > git clone https://github.com/htacg/tidy-html5.git > cd tidy-html5/build/cmake > cmake ../.. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local \ > -DBUILD_SHARED_LIB:BOOL=YES \ > -DTIDY_RC_NUMBER=next.2020.01.24 > make > > and everything looks normal until it gets to > -- Build files have been written to: /source/tidy/tidy-html5/build/cmake > e > [ 1%] o > [ 3%] > [ 5%] o > [ 7%] > [ 8%] o > [ 10%] o > [ 12%] o > [ 14%] o > [ 16%] o > [ > 17%] o > > [ 19%] o > > [ 21%] o > > [ 23%] o > > [ 25%] o > > [ 26%] > > [ 28%] o > > [ 30%] >[ 32%] o >[ 33%] o >[ 35%] o >[ 37%] >[ 39%] o >[ 41%] o >[ 42%] o >[ 44%] o >[ 46%] o > > [ 48%] l > > [ 48%] Built target tidy-share > c > [ 50%] o > [ 51%] > [ 53%] o > [ 55%] o > [ 57%] o > [ 58%] o > [ 60%] >[ 62%] o >[ 64%] >[ 66%] > o > > [ 67%] o > > [ 69%] o > > [ 71%] > > [ 73%] o > > [ 75%] o > > [ 76%] o > > [ 78%] >[ 80%] o >[ 82%] > [ 83%] o > [ 85%] o > [ 87%] o > [ 89%] o > [ 91%] o > [ 92%] > [ 94%] o > >[ 96%] a > >[ 96%] Built target tidy-static > y > [ 98%] o > [100%] e > [100%] Built target tidy > n > l > l >1 > [100%] Built target man > > -- > 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 > -- 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
terminal control chars broken?
New Windows 10 PC, new install of 64 bit cygwin, building tidy and the make progress indicator is displayed on a new line each time. Since it is a new machine/setup it's probably something I'm missing/ didn't install, but I have no idea what :( Any idea how to keep the progress indicator on the same line? mkdir /source cd /source mkdir tidy cd tidy git clone https://github.com/htacg/tidy-html5.git cd tidy-html5/build/cmake cmake ../.. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local \ -DBUILD_SHARED_LIB:BOOL=YES \ -DTIDY_RC_NUMBER=next.2020.01.24 make and everything looks normal until it gets to -- Build files have been written to: /source/tidy/tidy-html5/build/cmake e [ 1%] o [ 3%] [ 5%] o [ 7%] [ 8%] o [ 10%] o [ 12%] o [ 14%] o [ 16%] o [ 17%] o [ 19%] o [ 21%] o [ 23%] o [ 25%] o [ 26%] [ 28%] o [ 30%] [ 32%] o [ 33%] o [ 35%] o [ 37%] [ 39%] o [ 41%] o [ 42%] o [ 44%] o [ 46%] o [ 48%] l [ 48%] Built target tidy-share c [ 50%] o [ 51%] [ 53%] o [ 55%] o [ 57%] o [ 58%] o [ 60%] [ 62%] o [ 64%] [ 66%] o [ 67%] o [ 69%] o [ 71%] [ 73%] o [ 75%] o [ 76%] o [ 78%] [ 80%] o [ 82%] [ 83%] o [ 85%] o [ 87%] o [ 89%] o [ 91%] o [ 92%] [ 94%] o [ 96%] a [ 96%] Built target tidy-static y [ 98%] o [100%] e [100%] Built target tidy n l l 1 [100%] Built target man -- 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
Terminfo files not found?
Hello all, I seem to be running into an issue with my terminal not being recognized after updating to the latest terminfo (6.1-1.20190727). Setting TERM to anything other than 'xterm' results in loss of terminal control where I am unable to use backspace/delete/text editing commands. For example in tmux (with TERM set to 'tmux-256color') vim reports 'E558: Terminal entry not found in terminfo' and the output of infocmp shows 'infocmp: couldn't open terminfo file /usr/share/terminfo/74/tmux-256color' even through the file exists at that path with read access. Is anyone else running into this issue? I can revert to the previous version of terminfo and everything will work again, but after this long I'm surprised nobody else has brought this issue up. Alternatively there may be some kind of permissions issue on my end getting obscured by an otherwise noninformative error message. Some additional information that may be of relevance: $ stat /usr/share/terminfo/74/tmux-256color File: /usr/share/terminfo/74/tmux-256color Size: 3225Blocks: 4 IO Block: 65536 regular file Device: c6eca3b1h/3337397169d Inode: 1688849860292816 Links: 1 Access: (0644/-rw-r--r--) Uid: (197609/ jim) Gid: (197121/None) Access: 2020-01-23 15:21:27.671826400 -0800 Modify: 2019-07-28 09:49:23.0 -0700 Change: 2020-01-23 11:30:08.971083200 -0800 Birth: 2020-01-23 11:30:08.970087200 -0800 $ md5sum /usr/share/terminfo/74/tmux-256color 2d86e10db44e7d5032a13f9c229e0887 */usr/share/terminfo/74/tmux-256color -- 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
Bump DLL version to 3.1.3
Hello, The snapshot 20200114 was not announced (yet) however it seems that the usual "Bump DLL version to x.y.z" (with x.y.z=3.1.3) was not included (uname reports "3.1.2s"). Regards, Denis Excoffier. -- 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
Windows Restart Manager and cygrunsrv services
Good day, Application installers (such as Windows Installer or Inno Setup) can use the Windows Restart Manager APIs[1] it to determine if a program or service is running, and automatically stop/restart as appropriate. This is useful when reinstalling or upgrading a service from an installer, as the installer itself can stop the service, replace the binary/binaries, and restart the service automatically. However it seems that when running a service using cygrunsrv, the Restart Manager RmGetList API[2] returns RmRebootReasonSessionMismatch (2) for the lpdwRebootReasons output parameter. This parameter return value is one of the RM_REBOOT_REASON enumeration values[3]. The description for the RmRebootReasonSessionMismatch value on MSDN is as follows: "One or more processes are running in another Terminal Services session." I ran into this building an Inno Setup installer. I reproduced on Windows 10 x64 and Windows Server 2008 R2 x64. The error description is interesting, because in neither repro case were there other users logged on using TS sessions. (I'm not sure if that error description is completely accurate in describing all cases where that value gets returned, though...) Unexpected behavior: Restart Manager returns 2 (RmRebootReasonSessionMismatch) in the lpdwRebootReasons output parameter when calling the RmGetList API to detect a cygrunsrv service. Expected behavior: Restart Manager should return 0 (RmRebootReasonNone) in the lpdwRebootReasons output parameter when calling the RmGetList API to detect a cygrunsrv service. Further details (regarding Inno Setup and this problem): https://groups.google.com/d/msg/innosetup/9dAT3wB9RTQ/99Py-ZgLCgAJ Any ideas why Restart Manager doesn't work for cygrunsrv services? Thanks! Bill [1] https://docs.microsoft.com/en-us/windows/win32/rstmgr/about-restart-manager [2] https://docs.microsoft.com/en-us/windows/win32/api/restartmanager/nf-restartmanager-rmgetlist [3] https://docs.microsoft.com/en-us/windows/win32/api/restartmanager/ne-restartmanager-rm_reboot_reason -- 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
Re: [PATCH 0/3] Fix the O_PATH support for FIFOs
On 1/23/2020 11:31 AM, Ken Brown wrote:
> Commit aa55d22c, "Cygwin: honor the O_PATH flag when opening a FIFO",
> fixed a hang but otherwise didn't accomplish the purpose of the O_PATH
> flag as stated in the Linux man page for open(2):
>
> Obtain a file descriptor that can be used for two purposes: to
> indicate a location in the filesystem tree and to perform
> operations that act purely at the file descriptor level. The
> file itself is not opened, and other file operations (e.g.,
> read(2), write(2), fchmod(2), fchown(2), fgetxattr(2),
> ioctl(2), mmap(2)) fail with the error EBADF.
>
> [The man page goes on to describe operations that *can* be
> performed: close(2), fchdir(2), fstat(2),]
>
> Opening a file or directory with the O_PATH flag requires no
> permissions on the object itself (but does require execute
> permission on the directories in the path prefix).
>
> The first problem in the current implementation is that if open(2) is
> called on a FIFO, fhandler_base::device_access_denied is called and
> tries to open the FIFO with read access, which isn't supposed to be
> required. This is fixed by the first patch in this series.
>
> The second patch makes fhandler_fifo::open call fhandler_base::open_fs
> if O_PATH is set, so that we actually obtain a handle that can be used
> for the purposes stated above.
>
> The third page tweaks fhandler_fifo::fcntl and fhandler_fifo::dup so
> that they work with O_PATH.
>
> In a followup email I'll provide the program I used to test this
> implementation.
Test program attached.
$ gcc -o o_path_fifo_test o_path_fifo_test.c
$ ./o_path_fifo_test.exe
The following calls should fail with EBADF:
read: OK
write: OK
fchmod: OK
fchown: OK
ioctl: OK
fgetxattr: OK
mmap: OK
The following calls should succeed:
fstat: OK
fstatfs: OK
fcntl_dup: OK
fcntl_getfl: OK
fcntl_setfl: OK
fcntl_getfd: OK
fcntl_setfd: OK
close: OK
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define FIFO_PATH "/tmp/myfifo"
int
main ()
{
struct stat s;
int fd;
if (mkfifo (FIFO_PATH, S_IRUSR | S_IWUSR | S_IWGRP) < 0
&& errno != EEXIST)
{
perror ("mkfifo");
exit (1);
}
fd = open (FIFO_PATH, O_PATH);
if (fd < 0)
{
perror ("open");
exit (1);
}
printf ("The following calls should fail with EBADF:\n");
errno = 0;
if (read (fd, NULL, 0) < 0 && errno == EBADF)
printf ("read: OK\n");
else
perror ("read");
errno = 0;
if (write (fd, NULL, 0) < 0 && errno == EBADF)
printf ("write: OK\n");
else
perror ("write");
errno = 0;
if (fchmod (fd, 0) < 0 && errno == EBADF)
printf ("fchmod: OK\n");
else
perror ("fchmod");
errno = 0;
if (fchown (fd, -1, -1) < 0 && errno == EBADF)
printf ("fchown: OK\n");
else
perror ("fchown");
errno = 0;
if (ioctl (fd, FIONBIO, NULL) < 0 && errno == EBADF)
printf ("ioctl: OK\n");
else
perror ("ioctl");
errno = 0;
if (fgetxattr (fd, "", NULL, 0) < 0 && errno == EBADF)
printf ("fgetxattr: OK\n");
else
perror ("fgetxattr");
errno = 0;
if (mmap (NULL, 1, 0, MAP_SHARED, fd, 0) == MAP_FAILED && errno == EBADF)
printf ("mmap: OK\n");
else
perror ("mmap");
printf ("\nThe following calls should succeed:\n");
if (fstat (fd, ) < 0)
perror ("fstat");
else
printf ("fstat: OK\n");
struct statfs st;
if (fstatfs (fd, ) < 0)
perror ("fstatfs");
else
printf ("fstatfs: OK\n");
if (fcntl (fd, F_DUPFD, 0) < 0)
perror ("fcntl_dup");
else
printf ("fcntl_dup: OK\n");
int flags = fcntl (fd, F_GETFL);
if (flags < 0)
perror ("fcntl_getfl");
else
printf ("fcntl_getfl: OK\n");
if (flags >= 0)
{
if (fcntl (fd, F_SETFL, flags) < 0)
perror ("fcntl_setfl");
else
printf ("fcntl_setfl: OK\n");
}
flags = fcntl (fd, F_GETFD);
if (flags < 0)
perror ("fcntl_getfd");
else
printf ("fcntl_getfd: OK\n");
if (flags >= 0)
{
if (fcntl (fd, F_SETFD, flags) < 0)
perror ("fcntl_setfd");
else
printf ("fcntl_setfd: OK\n");
}
if (close (fd) < 0)
perror ("close");
else
printf ("close: OK\n");
}
Re: [PATCH] fhandler_proc.cc:format_proc_cpuinfo add rdpru flag
On 2020-01-23 05:44, Corinna Vinschen wrote: > On Jan 23 02:06, Brian Inglis wrote: >> rdpru flag is cpuid xfn 8008 ebx bit 4 added in linux 5.5; >> see AMD64 Architecture Programmerâs Manual Volume 3: >^ > This came over already broken. No idea if that's a problem of > your MUA or of the mailing list software. I fixed it to an > ordinary quote char locally. Sorry, didn't notice that sneaky quote from the PDF title in UTF-8 "’". Message source shows it's composed and sent in UTF-8 with: Content-Transfer-Encoding: 8bit by: X-Mailer: git-send-email 2.21.0 but without encoding or charset headers, so added git [sendemail] *Encoding config settings to avoid future issues by adding header (tested): Content-Type: text/plain; charset=UTF-8 -- 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.
[PATCH 0/3] Fix the O_PATH support for FIFOs
Commit aa55d22c, "Cygwin: honor the O_PATH flag when opening a FIFO", fixed a hang but otherwise didn't accomplish the purpose of the O_PATH flag as stated in the Linux man page for open(2): Obtain a file descriptor that can be used for two purposes: to indicate a location in the filesystem tree and to perform operations that act purely at the file descriptor level. The file itself is not opened, and other file operations (e.g., read(2), write(2), fchmod(2), fchown(2), fgetxattr(2), ioctl(2), mmap(2)) fail with the error EBADF. [The man page goes on to describe operations that *can* be performed: close(2), fchdir(2), fstat(2),] Opening a file or directory with the O_PATH flag requires no permissions on the object itself (but does require execute permission on the directories in the path prefix). The first problem in the current implementation is that if open(2) is called on a FIFO, fhandler_base::device_access_denied is called and tries to open the FIFO with read access, which isn't supposed to be required. This is fixed by the first patch in this series. The second patch makes fhandler_fifo::open call fhandler_base::open_fs if O_PATH is set, so that we actually obtain a handle that can be used for the purposes stated above. The third page tweaks fhandler_fifo::fcntl and fhandler_fifo::dup so that they work with O_PATH. In a followup email I'll provide the program I used to test this implementation. Ken Brown (3): Cygwin: device_access_denied: return false if O_PATH is set Cygwin: re-implement fhandler_fifo::open with O_PATH Cygwin: FIFO: tweak fcntl and dup when O_PATH is set winsup/cygwin/fhandler.cc | 3 +++ winsup/cygwin/fhandler_fifo.cc | 15 ++- 2 files changed, 9 insertions(+), 9 deletions(-) -- 2.21.0
[PATCH 2/3] Cygwin: re-implement fhandler_fifo::open with O_PATH
If the O_PATH flag is set, fhandler_fifo::open now simply calls
fhandler_base::open_fs.
The previous attempt to handle O_PATH in commit aa55d22c, "Cygwin:
honor the O_PATH flag when opening a FIFO", fixed a hang but otherwise
didn't do anything useful.
---
winsup/cygwin/fhandler_fifo.cc | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index fd8223000..8cbab353c 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -453,17 +453,13 @@ fhandler_fifo::open (int flags, mode_t)
} res;
if (flags & O_PATH)
-{
- query_open (query_read_attributes);
- nohandle (true);
-}
+return open_fs (flags);
/* Determine what we're doing with this fhandler: reading, writing, both */
switch (flags & O_ACCMODE)
{
case O_RDONLY:
- if (!query_open ())
- reader = true;
+ reader = true;
break;
case O_WRONLY:
writer = true;
@@ -585,8 +581,6 @@ fhandler_fifo::open (int flags, mode_t)
}
}
}
- if (query_open ())
-res = success;
out:
if (res == error_set_errno)
__seterrno ();
--
2.21.0
[PATCH 1/3] Cygwin: device_access_denied: return false if O_PATH is set
If O_PATH is set in the flags argument of
fhandler_base::device_access_denied, return false. No
read/write/execute access should be required in this case.
Previously, the call to device_access_denied in open(2) would lead to
an attempt to open the file with read access even if the O_PATH flag
was set.
---
winsup/cygwin/fhandler.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index b0c9c50c3..aeee8fe4d 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -335,6 +335,9 @@ fhandler_base::device_access_denied (int flags)
{
int mode = 0;
+ if (flags & O_PATH)
+return false;
+
if (flags & O_RDWR)
mode |= R_OK | W_OK;
if (flags & (O_WRONLY | O_APPEND))
--
2.21.0
[PATCH 3/3] Cygwin: FIFO: tweak fcntl and dup when O_PATH is set
fhandler_fifo::fcntl and fhandler_fifo::dup now call the corresponding
fhandler_base methods if the FIFO was opened with the O_PATH flag.
---
winsup/cygwin/fhandler_fifo.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index 8cbab353c..a338f12cc 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -997,7 +997,7 @@ fhandler_fifo::close ()
int
fhandler_fifo::fcntl (int cmd, intptr_t arg)
{
- if (cmd != F_SETFL || nohandle ())
+ if (cmd != F_SETFL || nohandle () || (get_flags () & O_PATH))
return fhandler_base::fcntl (cmd, arg);
const bool was_nonblocking = is_nonblocking ();
@@ -1014,6 +1014,9 @@ fhandler_fifo::dup (fhandler_base *child, int flags)
int ret = -1;
fhandler_fifo *fhf = NULL;
+ if (get_flags () & O_PATH)
+return fhandler_base::dup (child, flags);
+
if (fhandler_base::dup (child, flags))
goto out;
--
2.21.0
Re: cygrunsrv does not start cygsshd at boot
On Wed, Jan 22, 2020 at 03:08:12PM -0700, Brian Inglis wrote: > I've used dnscache for network service dependencies (and cygserver and > syslog-ng > for other Cygwin services) with delayed start and preshutdown (cygrunsrv -O, > --preshutdown). > Where previous usage was cygrunsrv -t, --type manual is now called demand > service startup type. > > You can set service startup type using: > > $ sc config cygsshd start= boot|system|auto|demand|disabled|delayed-auto > # option flag requires = and the value must be a separate argument ... > $ sc query cygsshd ... > $ regtool -pv list > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cygsshd/ > ... > $ regtool -pv list > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cygsshd/Parameters/ > ... > As the reg entries show, you can also do this by adding or setting registry > entries using Cygwin regtool, Windows reg, or regedit commands. Thanks. I was not familiar with the sc and regtool commands. For now, using automatic (delayed start) seems to be adequate for solving my problem. Regards, Andy -- 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
Re: [ANNOUNCEMENT] lftp 4.9.0-2
> This was already fixed on lftp 4.9.1 released by the developer. You should > probably just release that version instead of the patched version. OK, yep. Thanks. -- 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
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Thu, 23 Jan 2020 13:51:54 +0100 Corinna Vinschen wrote: > On Jan 23 13:30, Takashi Yano wrote: > > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of > > cygwin programs which call both printf() and WriteConsole() are > > frequently distorted. This patch reverts waiting function to dumb > > Sleep(). > I understand the need for this change, but isn't there any other > way to detect if the pseudo console being ready? E. g., something > in the HPCON_INTERNAL struct or so? In any case, this patch has a problem that windows native program takes a very long time to start/stop after the window size is changed. Please do not apply this patch. If you want to try this patch, please use following patch along with v2 patch. diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc index 2b7c667a6..06ac0c5e0 100644 --- a/winsup/cygwin/fhandler_tty.cc +++ b/winsup/cygwin/fhandler_tty.cc @@ -2413,6 +2413,7 @@ fhandler_pty_master::ioctl (unsigned int cmd, void *arg) COORD size; size.X = ((struct winsize *) arg)->ws_col; size.Y = ((struct winsize *) arg)->ws_row; + get_ttyp ()->last_push_time = GetTickCount (); ResizePseudoConsole (get_pseudo_console (), size); } if (get_ttyp ()->winsize.ws_row != ((struct winsize *) arg)->ws_row -- Takashi Yano
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
2020年1月23日(木) 22:00 Takashi Yano : > Is there any process alived using diffrent version of cygwin1.dll? Ah, you were right! Actually there were no *real* processes remained (Otherwise I could not have overwritten cygwin1.dll, I think), but I remembered that there is a remaining *fake entry* in the result of `ps' as follows (for which `kill' produces error `No such process' and also I cannot find any corresponding process in Windows Task Manager). $ ps uaxf PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 1416 11416 11160 ? 197610 Jan 20 /home/murase/opt/screen/4.7.0m/bin/screen-4.7.0 After a reboot of Windows, the problem has resolved! Thank you! Koichi
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Thu, 23 Jan 2020 13:51:54 +0100
Corinna Vinschen wrote:
> On Jan 23 13:30, Takashi Yano wrote:
> > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of
> > cygwin programs which call both printf() and WriteConsole() are
> > frequently distorted. This patch reverts waiting function to dumb
> > Sleep().
>
> I understand the need for this change, but isn't there any other
> way to detect if the pseudo console being ready? E. g., something
> in the HPCON_INTERNAL struct or so?
As for HPCON_INTERNAL,
typedef struct _HPCON_INTERNAL
{
HANDLE hWritePipe;
HANDLE hConDrvReference;
HANDLE hConHostProcess;
} HPCON_INTERNAL;
hWritePipe:
This is for sending window size change message to pseudo console
(conhost.exe process).
hConDrvRererence:
I am not sure what this is for.
hConHostProcess:
Process handle of conhost.exe process.
None of them seems able to be used for that purpose.
I do not come up with other implementation so far.
Let me consider a while.
--
Takashi Yano
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Thu, 23 Jan 2020 21:39:50 +0800 Koichi Murase wrote: > 0 [main] () shared_info::initialize: size of shared > memory region changed from 50104 to 49080 Is there any process alived using diffrent version of cygwin1.dll? -- Takashi Yano
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
2020年1月23日(木) 21:39 Koichi Murase : > > On Jan 23 13:30, Takashi Yano wrote: > > > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of > > > cygwin programs which call both printf() and WriteConsole() are > > > frequently distorted. This patch reverts waiting function to dumb > > > Sleep(). I'm sorry, I made a reply to a wrong mail (with a similar subject). I should have made this reply to the original version of the patch. Sorry for the confusion. Koichi
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
> On Jan 23 13:30, Takashi Yano wrote: > > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of > > cygwin programs which call both printf() and WriteConsole() are > > frequently distorted. This patch reverts waiting function to dumb > > Sleep(). Hi, I have a question related to this patch. (When I have a question on a specific patch like this, which mailing list should I come? If I should not make a reply to the original cygwin-patch mailing list, let me apologize in advance. If so, I'll move to cygwin mailing list.) When I try to use the recent commit 6d79e0a58 (tag: newlib-3.3.0), any Cygwin program fails to start leaving the following message: 0 [main] () shared_info::initialize: size of shared memory region changed from 50104 to 49080 where and are the program name and PID. I also tried with the current master branch 8f502bd33, and the result was the same. I tested each commit one by one, and found that this problem is caused after this patch: 6cc299f0e - (2 days ago) Cygwin: pty: Revise code waiting for forwarding by master_fwd_thread. - Takashi Yano In fact, if I drop this commit from the master branch, the problem disappears. But, as there are no related reports here, I suspect this is the problem specific to my environment. In particular, I suspect that this is caused by the compatibility of different versions of `cygwin1.dll'. Currently, when I try to use the new `cygwin1.dll', I just replace `C:\cygwin64\bin\cygwin1.dll' with the version I built from recent a commit (`new-cygwin1.dll') following the instruction for snapshots which is found at https://cygwin.com/faq.html#faq.setup.snapshots Here my question is, if this is caused by the way I try the new version, what is the correct way to try the latest version built from a commit in the git repository (do I need to rebuild all the toolchain)? Or, is this problem caused by other conditions? I would appreciate it if you could provide me some hints. Here is some trials in command prompt: C:\cygwin64\bin>bash 0 [main] bash (18936) shared_info::initialize: size of shared memory region changed from 50104 to 49080 C:\cygwin64\bin>dash 0 [main] dash (7900) shared_info::initialize: size of shared memory region changed from 50104 to 49080 C:\cygwin64\bin>stty 0 [main] stty (2920) shared_info::initialize: size of shared memory region changed from 50104 to 49080 C:\cygwin64\bin>cat 0 [main] cat (21340) shared_info::initialize: size of shared memory region changed from 50104 to 49080 C:\cygwin64\bin>mintty mintty fails without any messages. Thank you, Koichi
Re: [PATCH] Cygwin: pty: Add missing console API hooks.
On Thu, 23 Jan 2020 13:48:13 +0100
Corinna Vinschen wrote:
> On Jan 23 13:33, Takashi Yano wrote:
> > - Following console APIs are additionally hooked for cygwin programs
> > which directly call them.
> > * FillConsoleOutputAttribute()
> > * FillConsoleOutputCharacterA()
> > * FillConsoleOutputCharacterW()
> > * ScrollConsoleScreenBufferA()
> > * ScrollConsoleScreenBufferW()
>
> Which Cygwin programs are doing that? They wouldn't work correctly in
> ptys anyway, isn't it? Does it really make sense to make them happy
> rather than requesting to change them?
Just a possibility. There is no specific example.
With this patch, the code below can work even if it is compiled as
cygwin binary.
#include
#include
int main() {
COORD dest = {0, 0};
printf("\033[H\033[J\n");
DWORD n;
FillConsoleOutputCharacter (GetStdHandle(STD_OUTPUT_HANDLE),
'A', 80, dest, );
FillConsoleOutputAttribute (GetStdHandle(STD_OUTPUT_HANDLE),
FOREGROUND_RED, 80, dest, );
return 0;
}
--
Takashi Yano
Re: cgdb terminal handling problems
On Sat, 18 Jan 2020 13:11:40 +0900 Takashi Yano wrote: > On Fri, 17 Jan 2020 16:40:03 + (GMT Standard Time) > Arthur Norman wrote: > > [80X[80C[?25h[?25lbreakpoints-invalid[?25h[?25l > > [80X[80C[?25h[?25l[80X[80C[?25h[?25l > > Breakpoint 1,[67X[67C[?25h[?25l[80X[80C[?25h[?25lmain[76X[76C[?25h[?25l > > ([78X[78 > > C[?25h[?25largc[76X[76C[?25h[?25l=[79X[79C[?25h[?25l1[79X[79C[?25h[?25l,[79X[79C > > [?25h[?25largv[76X[76C[?25h[?25l=[79X[79C[?25h[?25l > > [80X[80C[?25h[?25larg-value *[?25h[?25l > > 0xcc40[70X[70C[?25h[?25l)[79X[79C[?25h[?25l > > at[77X[77C[?25h[?25lhello.cpp[71 > > X[71C[?25h[?25l:[79X[79C[?25h[?25l5[79X[79C[?25h[?25l[80X[80C[?25h[?25l[?25h[?25 > > l > > [80X[80C[?25h[?25l[80X[80C[?25h[?25l[80X[80C[?25h[?25l[80X[80C[?25h[?25l(gdb)[75 > > X[75C[?25h[?25l > > This is obviously a pseudo console related issue. > Please give me time. I propose a patch which able to disable the pseudo console featre in pty, and it was accepted. With this patch, cgdb can work as before by: env CYGWIN=disable_pcon cgdb progname You can also use alias alias cgdb="env CYGWIN=disable_pcon cgdb" Please wait for new cygwin release. -- Takashi Yano -- 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
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Jan 23 13:30, Takashi Yano wrote: > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of > cygwin programs which call both printf() and WriteConsole() are > frequently distorted. This patch reverts waiting function to dumb > Sleep(). I understand the need for this change, but isn't there any other way to detect if the pseudo console being ready? E. g., something in the HPCON_INTERNAL struct or so? Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: pty: Add missing console API hooks.
On Jan 23 13:33, Takashi Yano wrote: > - Following console APIs are additionally hooked for cygwin programs > which directly call them. > * FillConsoleOutputAttribute() > * FillConsoleOutputCharacterA() > * FillConsoleOutputCharacterW() > * ScrollConsoleScreenBufferA() > * ScrollConsoleScreenBufferW() Which Cygwin programs are doing that? They wouldn't work correctly in ptys anyway, isn't it? Does it really make sense to make them happy rather than requesting to change them? Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] fhandler_proc.cc:format_proc_cpuinfo add rdpru flag
On Jan 23 02:06, Brian Inglis wrote: > rdpru flag is cpuid xfn 8008 ebx bit 4 added in linux 5.5; > see AMD64 Architecture Programmerâs Manual Volume 3: ^ This came over already broken. No idea if that's a problem of your MUA or of the mailing list software. I fixed it to an ordinary quote char locally. > General-Purpose and System Instructions > https://www.amd.com/system/files/TechDocs/24594.pdf#page=329 > and elsewhere in that document > > --- > winsup/cygwin/fhandler_proc.cc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc > index 8c331f5f4..78a69703d 100644 > --- a/winsup/cygwin/fhandler_proc.cc > +++ b/winsup/cygwin/fhandler_proc.cc > @@ -1255,6 +1255,7 @@ format_proc_cpuinfo (void *, char *) > ftcprint (features1, 0, "clzero"); /* clzero instruction */ > ftcprint (features1, 1, "irperf"); /* instr retired count */ > ftcprint (features1, 2, "xsaveerptr"); /* save/rest FP err ptrs */ > + ftcprint (features1, 4, "rdpru");/* user level rd proc reg */ > /* ftcprint (features1, 6, "mba"); */ /* memory BW alloc */ > ftcprint (features1, 9, "wbnoinvd"); /* wbnoinvd instruction */ > /* ftcprint (features1, 12, "ibpb" ); */ /* ind br pred barrier */ > -- > 2.21.0 Pushed. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: pty: Remove close() call just before reopening slave.
On Jan 23 20:34, Takashi Yano wrote:
> - After commit da4ee7d60b9ff0bcdc081609a4467adb428d58e6, the issue
> reported in https://www.cygwin.com/ml/cygwin/2020-01/msg00209.html
> occurs. This patch fixes the issue.
> ---
> winsup/cygwin/fhandler_tty.cc | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> index 73aeff37f..35a48338f 100644
> --- a/winsup/cygwin/fhandler_tty.cc
> +++ b/winsup/cygwin/fhandler_tty.cc
> @@ -1326,7 +1326,6 @@ fhandler_pty_slave::push_to_pcon_screenbuffer (const
> char *ptr, size_t len)
> {
>termios_printf ("GetConsoleMode failed, %E");
>/* Re-open handles */
> - this->close ();
>this->open (0, 0);
>/* Fix pseudo console window size */
>this->ioctl (TIOCSWINSZ, _ttyp ()->winsize);
> --
> 2.21.0
Pushed.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
[newlib-cygwin] fhandler_proc.cc:format_proc_cpuinfo add rdpru flag
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=8f502bd33159cfe0f138a31442998a77602c8a9a commit 8f502bd33159cfe0f138a31442998a77602c8a9a Author: Brian Inglis Date: Thu Jan 23 02:06:27 2020 -0700 fhandler_proc.cc:format_proc_cpuinfo add rdpru flag rdpru flag is cpuid xfn 8008 ebx bit 4 added in linux 5.5; see AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions https://www.amd.com/system/files/TechDocs/24594.pdf#page=329 and elsewhere in that document Diff: --- winsup/cygwin/fhandler_proc.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc index 8c331f5..78a6970 100644 --- a/winsup/cygwin/fhandler_proc.cc +++ b/winsup/cygwin/fhandler_proc.cc @@ -1255,6 +1255,7 @@ format_proc_cpuinfo (void *, char *) ftcprint (features1, 0, "clzero"); /* clzero instruction */ ftcprint (features1, 1, "irperf"); /* instr retired count */ ftcprint (features1, 2, "xsaveerptr"); /* save/rest FP err ptrs */ + ftcprint (features1, 4, "rdpru");/* user level rd proc reg */ /* ftcprint (features1, 6, "mba"); */ /* memory BW alloc */ ftcprint (features1, 9, "wbnoinvd"); /* wbnoinvd instruction */ /* ftcprint (features1, 12, "ibpb" ); */ /* ind br pred barrier */
[newlib-cygwin] Cygwin: pty: Remove close() call just before reopening slave.
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=5fdcb8fc135a14846cc37d30cb11d1590e5113b8
commit 5fdcb8fc135a14846cc37d30cb11d1590e5113b8
Author: Takashi Yano
Date: Thu Jan 23 20:34:25 2020 +0900
Cygwin: pty: Remove close() call just before reopening slave.
- After commit da4ee7d60b9ff0bcdc081609a4467adb428d58e6, the issue
reported in https://www.cygwin.com/ml/cygwin/2020-01/msg00209.html
occurs. This patch fixes the issue.
Diff:
---
winsup/cygwin/fhandler_tty.cc | 1 -
1 file changed, 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 1710f25..4977a8b 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -1281,7 +1281,6 @@ fhandler_pty_slave::push_to_pcon_screenbuffer (const char
*ptr, size_t len)
{
termios_printf ("GetConsoleMode failed, %E");
/* Re-open handles */
- this->close ();
this->open (0, 0);
/* Fix pseudo console window size */
this->ioctl (TIOCSWINSZ, _ttyp ()->winsize);
[PATCH] Cygwin: pty: Remove close() call just before reopening slave.
- After commit da4ee7d60b9ff0bcdc081609a4467adb428d58e6, the issue
reported in https://www.cygwin.com/ml/cygwin/2020-01/msg00209.html
occurs. This patch fixes the issue.
---
winsup/cygwin/fhandler_tty.cc | 1 -
1 file changed, 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 73aeff37f..35a48338f 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -1326,7 +1326,6 @@ fhandler_pty_slave::push_to_pcon_screenbuffer (const char
*ptr, size_t len)
{
termios_printf ("GetConsoleMode failed, %E");
/* Re-open handles */
- this->close ();
this->open (0, 0);
/* Fix pseudo console window size */
this->ioctl (TIOCSWINSZ, _ttyp ()->winsize);
--
2.21.0
Re: Cygwin 3.3.0: The programs compiled with "-mwindows" cannot read more than one byte from noncanonical mode TTY
On Thu, 23 Jan 2020 18:49:04 +0800 Koichi Murase wrote: > 2020年1月21日(火) 10:47 Takashi Yano : > > Thanks for the report. I could reproduce the problem under LANG=ja_JP.UTF-8. > > I have almost caught the culprit. Please wait for a while. > > Thank you for the patch fixing the problem. I cherry-picked the patch > and tried it, but there is another problem. > > Description: > > The programs compiled with "-mwindows" cannot read more than one > character from PTY in a non-canonical mode in . There was no > problem before the patch "Cygwin: pty: Fix reopening slave in > push_to_pcon_screenbuffer().". > > Repeat-By: > > 1. Open Cygwin Terminal (mintty) > > 2. Compile the attached program with the following commands. > > $ g++ -o minimal2-con.exe minimal2.cpp > $ g++ -mwindows -o minimal2-win.exe minimal2.cpp > > 3. The expected behavior can be checked with `minimal2-con'. After > executing the command, please type some five characters. The > string `[RECV]' will be printed five times, and then the program > will exit. > > $ ./minimal2-con > [RECV][RECV][RECV][RECV][RECV] > $ > > 4. However, with the compile option "-mwindows", we can only see one > `[RECV]', and the program will hang. > > $ ./minimal2-win > [RECV] Thanks for the report again. Apparently, close() before reopening slave which I added just in case was superfluous. I will submit a patch for this issue. -- Takashi Yano -- 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
Cygwin 3.3.0: The programs compiled with "-mwindows" cannot read more than one byte from noncanonical mode TTY
2020年1月21日(火) 10:47 Takashi Yano :
> Thanks for the report. I could reproduce the problem under LANG=ja_JP.UTF-8.
> I have almost caught the culprit. Please wait for a while.
Thank you for the patch fixing the problem. I cherry-picked the patch
and tried it, but there is another problem.
Description:
The programs compiled with "-mwindows" cannot read more than one
character from PTY in a non-canonical mode in . There was no
problem before the patch "Cygwin: pty: Fix reopening slave in
push_to_pcon_screenbuffer().".
Repeat-By:
1. Open Cygwin Terminal (mintty)
2. Compile the attached program with the following commands.
$ g++ -o minimal2-con.exe minimal2.cpp
$ g++ -mwindows -o minimal2-win.exe minimal2.cpp
3. The expected behavior can be checked with `minimal2-con'. After
executing the command, please type some five characters. The
string `[RECV]' will be printed five times, and then the program
will exit.
$ ./minimal2-con
[RECV][RECV][RECV][RECV][RECV]
$
4. However, with the compile option "-mwindows", we can only see one
`[RECV]', and the program will hang.
$ ./minimal2-win
[RECV]
Best,
Koichi
#include
#include
int main() {
struct termios oldTermios;
tcgetattr(STDIN_FILENO, );
struct termios termios = oldTermios;
termios.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG);
termios.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON);
termios.c_cflag &= ~(CSIZE | PARENB);
termios.c_cflag |= CS8;
termios.c_oflag &= ~(OPOST);
termios.c_cc[VMIN] = 1;
termios.c_cc[VTIME] = 0;
tcsetattr(STDIN_FILENO, TCSAFLUSH, );
for (int i = 0; i < 5; i++) {
char c;
int const nread = read(STDIN_FILENO, , 1);
write(STDOUT_FILENO, nread > 0 ? "[RECV]" : "[FAIL]", 6);
}
tcsetattr(STDIN_FILENO, TCSAFLUSH, );
write(STDOUT_FILENO, "\n", 1);
return 0;
}
--
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
[PATCH] fhandler_proc.cc:format_proc_cpuinfo add rdpru flag
rdpru flag is cpuid xfn 8008 ebx bit 4 added in linux 5.5; see AMD64 Architecture Programmerâs Manual Volume 3: General-Purpose and System Instructions https://www.amd.com/system/files/TechDocs/24594.pdf#page=329 and elsewhere in that document --- winsup/cygwin/fhandler_proc.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc index 8c331f5f4..78a69703d 100644 --- a/winsup/cygwin/fhandler_proc.cc +++ b/winsup/cygwin/fhandler_proc.cc @@ -1255,6 +1255,7 @@ format_proc_cpuinfo (void *, char *) ftcprint (features1, 0, "clzero"); /* clzero instruction */ ftcprint (features1, 1, "irperf"); /* instr retired count */ ftcprint (features1, 2, "xsaveerptr"); /* save/rest FP err ptrs */ + ftcprint (features1, 4, "rdpru");/* user level rd proc reg */ /* ftcprint (features1, 6, "mba"); */ /* memory BW alloc */ ftcprint (features1, 9, "wbnoinvd"); /* wbnoinvd instruction */ /* ftcprint (features1, 12, "ibpb" ); */ /* ind br pred barrier */ -- 2.21.0
