Re: mintty ^H weirdness with ssh to one specific Debian 11 system
On 1/18/2024 06:14, Thomas Wolff via Cygwin wrote: Am 18.01.2024 um 14:08 schrieb Andrey Repin via Cygwin: Greetings, Jim Garrison via Cygwin! Details I have mintty set to term type "mintty" Don't do that. $TERM is not a random made-up string. It should be supported by appropriate terminfo(5) entry on the system. If an entry is not found, it will fall back to some other entry, which could be 'vt100' or even 'dumb', which is not what you want, certainly. Yes, I forgot to mention that. One way to check whether a terminal description addressed by your $TERM value is actually installed on the system, is to run the tool `infocmp`. Thanks to those who replied. In the inimitable words of one Miss Emily Litella (Gilda Radner) "Never Mind!" (L)user error. My apologies for the noise. -- Jim Garrison j...@acm.org -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty ^H weirdness with ssh to one specific Debian 11 system
Am 18.01.2024 um 14:08 schrieb Andrey Repin via Cygwin: Greetings, Jim Garrison via Cygwin! Details I have mintty set to term type "mintty" Don't do that. $TERM is not a random made-up string. It should be supported by appropriate terminfo(5) entry on the system. If an entry is not found, it will fall back to some other entry, which could be 'vt100' or even 'dumb', which is not what you want, certainly. Yes, I forgot to mention that. One way to check whether a terminal description addressed by your $TERM value is actually installed on the system, is to run the tool `infocmp`. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty ^H weirdness with ssh to one specific Debian 11 system
Greetings, Jim Garrison via Cygwin! > Details > I have mintty set to term type "mintty" Don't do that. $TERM is not a random made-up string. It should be supported by appropriate terminfo(5) entry on the system. If an entry is not found, it will fall back to some other entry, which could be 'vt100' or even 'dumb', which is not what you want, certainly. -- With best regards, Andrey Repin Thursday, January 18, 2024 16:05:02 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty ^H weirdness with ssh to one specific Debian 11 system
Am 16.01.2024 um 22:38 schrieb Jim Garrison via Cygwin: TL;DR New laptop, setting up mintty configuration identical to working desktop system. When connected to one specific Debian 11 (Bullseye) system (to which I connect often from the desktop with no issues), backspace appears to send ^H, and Debian interprets ^H correctly, but the terminal display echoes a space character instead of backing up one space. Details I have mintty set to term type "mintty" and "Keys/Backarrow sends ^H". A little experimentation shows that the Debian system is correctly interpreting the backspace, only the mintty display is incorrect. I guess there are two possibilities: * Debian is echoing a blank when receiving ^H * mintty is not correctly displaying the ^H echoed by Debian Note, a local mintty session is NOT affected, backspace works fine there. Also note when I ssh to a Debian 12 system and an old CentOS 7 system I don't see this issue, and when connecting from my desktop all three systems work. I am stumped for how to troubleshoot this further. I diffed the output of "stty -a" between the non-working system and one that works. The only differences are: Working system: eol = ; eol2 = ; Non-working system: eol = M-^?; eol2 = M-^?; cygcheck.out attached On the Debian 11 (non-working) system: jhg@smtp ~ $ echo $TERM mintty jhg@smtp ~ $ stty -a speed 38400 baud; rows 37; columns 128; line = 0; intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc You've verified the stty setting 'erase' above, please also verify the mintty behaviour, e.g. with ^V Backarrow in a command line (to echo the character as ^H, hopefully) to check that the two settings match consistently. I've noticed myself on an older Debian system that behaviour of the 'erase' character may be weird; it initially worked as expected with ^H, then I switched to stty erase ^?, then back to ^H, and behaviour was different: ^H did not erase a character anymore but echoed "^H". Anyway, this is handling of the shell (or realine library) and not under control of mintty. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
On 2023-08-25, Jim Garrison via Cygwin wrote: > On 8/25/2023 00:18, Backwoods BC via Cygwin wrote: > [snip] > > > >I get borders around both active and inactive windows, but then I've > >spent hours (probably days) messing with registry values in an attempt > >to gain the kind of UI control that was built into XP. I don't know > >which change I made that gave me borders, but it is possible. > > > [snip] > > In my setup (plain Win11 without registry hacks) the border is > highlighted on the focused window, and other windows have a much > fainter border, just enough to be visible when you have multiple > overlapping minttys with black background. Not sure if this was > the case on Win10 as well. I see that now on my Windows 10 machine. I don't know why I didn't notice it before. Perhaps the accent color was too dark. I changed the accent color to white, which doesn't seem to interfere with my color scheme, and paid more attention to overlapping mintty and gvim windows (which have black backgrounds), and as you say, it's faint but there. Regards, Gary -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
On 8/25/2023 00:18, Backwoods BC via Cygwin wrote: [snip] I get borders around both active and inactive windows, but then I've spent hours (probably days) messing with registry values in an attempt to gain the kind of UI control that was built into XP. I don't know which change I made that gave me borders, but it is possible. [snip] In my setup (plain Win11 without registry hacks) the border is highlighted on the focused window, and other windows have a much fainter border, just enough to be visible when you have multiple overlapping minttys with black background. Not sure if this was the case on Win10 as well. -- Jim Garrison j...@acm.org -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
On 25/08/2023 08:18, Backwoods BC via Cygwin wrote: > On Thu, Aug 24, 2023 at 10:54 PM Gary Johnson via Cygwin > wrote: >> >> On 2023-08-25, Thomas Wolff via Cygwin wrote: >>> >>> >>> Am 25.08.2023 um 02:41 schrieb Gary Johnson via Cygwin: On 2023-08-24, Backwoods BC via Cygwin wrote: > On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin > wrote: >> This is an update to a question I had a couple of years ago >> https://cygwin.com/pipermail/cygwin/2021-April/248367.html >> >> Windows 11 now has an "accent color" option under >> Settings/Personalization/Colors that adds a thin (1px?) border around >> all windows, in a user-selectable color. This definitively eliminates >> the problem seen with overlapping mintty windows that have a dark grey >> or black background (where the shadow isn't visible). >> >> Just FYI >> >> -- >> Jim Garrison >> j...@acm.org > This is also true for Windows 10, although I may have had to > explicitly enable it (I don't remember). It's in the same place on Windows 10. I just enabled it. Thank you both! >>> But it adds the thin border only to the foreground window... >>> Thomas >> >> Yes, it's not as good as having a border around all windows all the >> time, or around just mintty and gvim windows, but it is so much >> better than nothing at all, or so it seems so far. >> >> Regards, >> Gary > > I get borders around both active and inactive windows, but then I've > spent hours (probably days) messing with registry values in an attempt > to gain the kind of UI control that was built into XP. I don't know > which change I made that gave me borders, but it is possible. > > Any combination of these changes may have done it -- or none of them > (I changed a lot of things): > [snip] In Windows 10, I've managed to get inactive window title bars white with a dark accent and active dark with a white accent colour around without resorting to registry hacking. I'm using a solid black background, 'Light' colour setting and auto-selected accent colour in Preferences. I've also enabled the accent colour on title bars and window borders checkbox. I still have problems with non-compliant "I'll draw it myself" apps that don't use the stock furniture but it works for mintty at least. I'm baffled as to why a UI designer would introduce a feature that makes it difficult if not impossible to see the edges of windows in the first place but that's Microsoft all over. :-S -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
On Thu, Aug 24, 2023 at 10:54 PM Gary Johnson via Cygwin wrote: > > On 2023-08-25, Thomas Wolff via Cygwin wrote: > > > > > > Am 25.08.2023 um 02:41 schrieb Gary Johnson via Cygwin: > > >On 2023-08-24, Backwoods BC via Cygwin wrote: > > >>On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin > > >> wrote: > > >>>This is an update to a question I had a couple of years ago > > >>>https://cygwin.com/pipermail/cygwin/2021-April/248367.html > > >>> > > >>>Windows 11 now has an "accent color" option under > > >>>Settings/Personalization/Colors that adds a thin (1px?) border around > > >>>all windows, in a user-selectable color. This definitively eliminates > > >>>the problem seen with overlapping mintty windows that have a dark grey > > >>>or black background (where the shadow isn't visible). > > >>> > > >>>Just FYI > > >>> > > >>>-- > > >>>Jim Garrison > > >>>j...@acm.org > > >>This is also true for Windows 10, although I may have had to > > >>explicitly enable it (I don't remember). > > >It's in the same place on Windows 10. I just enabled it. Thank you both! > > But it adds the thin border only to the foreground window... > > Thomas > > Yes, it's not as good as having a border around all windows all the > time, or around just mintty and gvim windows, but it is so much > better than nothing at all, or so it seems so far. > > Regards, > Gary I get borders around both active and inactive windows, but then I've spent hours (probably days) messing with registry values in an attempt to gain the kind of UI control that was built into XP. I don't know which change I made that gave me borders, but it is possible. Any combination of these changes may have done it -- or none of them (I changed a lot of things): [HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM] "AccentColorInactive"=dword:00ccddee [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Accent] "MotionAccentId_v1.00"=dword:00db "AccentPalette"=hex:a9,ef,ff,00,79,e6,ff,00,48,d2,f2,00,00,99,bc,00,00,6b,83,\ 00,00,4b,5c,00,00,32,3d,00,e3,00,8c,00 "StartColorMenu"=dword:ff836b00 "AccentColorMenu"=dword:ffbc9900 "TaskbarColorOverride"=dword: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System] "NoSizeChoice"=dword: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System] "NoDispBackgroundPage"=dword: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System] "NoDispScrSavPage"=dword: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System] "NoDispCPL"=dword: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System] "NoDispSettingsPage"=dword: -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
On 2023-08-25, Thomas Wolff via Cygwin wrote: > > > Am 25.08.2023 um 02:41 schrieb Gary Johnson via Cygwin: > >On 2023-08-24, Backwoods BC via Cygwin wrote: > >>On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin > >> wrote: > >>>This is an update to a question I had a couple of years ago > >>>https://cygwin.com/pipermail/cygwin/2021-April/248367.html > >>> > >>>Windows 11 now has an "accent color" option under > >>>Settings/Personalization/Colors that adds a thin (1px?) border around > >>>all windows, in a user-selectable color. This definitively eliminates > >>>the problem seen with overlapping mintty windows that have a dark grey > >>>or black background (where the shadow isn't visible). > >>> > >>>Just FYI > >>> > >>>-- > >>>Jim Garrison > >>>j...@acm.org > >>This is also true for Windows 10, although I may have had to > >>explicitly enable it (I don't remember). > >It's in the same place on Windows 10. I just enabled it. Thank you both! > But it adds the thin border only to the foreground window... > Thomas Yes, it's not as good as having a border around all windows all the time, or around just mintty and gvim windows, but it is so much better than nothing at all, or so it seems so far. Regards, Gary -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
Am 25.08.2023 um 02:41 schrieb Gary Johnson via Cygwin: On 2023-08-24, Backwoods BC via Cygwin wrote: On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin wrote: This is an update to a question I had a couple of years ago https://cygwin.com/pipermail/cygwin/2021-April/248367.html Windows 11 now has an "accent color" option under Settings/Personalization/Colors that adds a thin (1px?) border around all windows, in a user-selectable color. This definitively eliminates the problem seen with overlapping mintty windows that have a dark grey or black background (where the shadow isn't visible). Just FYI -- Jim Garrison j...@acm.org This is also true for Windows 10, although I may have had to explicitly enable it (I don't remember). It's in the same place on Windows 10. I just enabled it. Thank you both! But it adds the thin border only to the foreground window... Thomas Regards, Gary -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
On 2023-08-24, Backwoods BC via Cygwin wrote: > On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin > wrote: > > > > This is an update to a question I had a couple of years ago > > https://cygwin.com/pipermail/cygwin/2021-April/248367.html > > > > Windows 11 now has an "accent color" option under > > Settings/Personalization/Colors that adds a thin (1px?) border around > > all windows, in a user-selectable color. This definitively eliminates > > the problem seen with overlapping mintty windows that have a dark grey > > or black background (where the shadow isn't visible). > > > > Just FYI > > > > -- > > Jim Garrison > > j...@acm.org > > This is also true for Windows 10, although I may have had to > explicitly enable it (I don't remember). It's in the same place on Windows 10. I just enabled it. Thank you both! Regards, Gary -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
On Thu, Aug 24, 2023 at 11:08 AM Jim Garrison via Cygwin wrote: > > This is an update to a question I had a couple of years ago > https://cygwin.com/pipermail/cygwin/2021-April/248367.html > > Windows 11 now has an "accent color" option under > Settings/Personalization/Colors that adds a thin (1px?) border around > all windows, in a user-selectable color. This definitively eliminates > the problem seen with overlapping mintty windows that have a dark grey > or black background (where the shadow isn't visible). > > Just FYI > > -- > Jim Garrison > j...@acm.org This is also true for Windows 10, although I may have had to explicitly enable it (I don't remember). -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
This is an update to a question I had a couple of years ago https://cygwin.com/pipermail/cygwin/2021-April/248367.html Windows 11 now has an "accent color" option under Settings/Personalization/Colors that adds a thin (1px?) border around all windows, in a user-selectable color. This definitively eliminates the problem seen with overlapping mintty windows that have a dark grey or black background (where the shadow isn't visible). Just FYI -- Jim Garrison j...@acm.org -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty 3.6.4 status line problem
Am 18.06.2023 um 22:00 schrieb Ross Boulet via Cygwin: I was looking at the settings for mintty and saw the new option (new as of 3.6.4 from March) for a status line. I decided to try it out. Sure enough, a status line appeared at the bottom. All was well until I tried to open a new mintty window and nothing seemed to happen. After a little research, I saw a stackdump was being generated. I had to get to the .minttyrc file and remove the StatusLine=yes to get it to work again. I tried the same scenario on another Windows 10 machine as well as a Windows 11 machine with the same results. To reproduce the problem, right click on the icon in the upper left corner of a mintty window and choose options. On the options dialog, choose terminal and check the option to turn on the status line. Then click save. The current window shows a status line but attempts to start a new window will fail and generate a stackdump. This issue occurs if the monitor DPI is 96 (or 100% display scaling). It was fixed in the repository already. Still working on some other issues before a release though. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: mintty mouse behavior with vim
On May 18, 2023 5:12 PM, Brian Inglis expressed: > > That will depend on the client installed on the remote host! > Get them to upgrade to gvim 9 as on Windows ;^> I don't think that will do anything. :-) This is the ubuntu version: jic@web:~/w/default.website$ gvim --version VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Apr 18 2023 11:40:57) Included patches: 1-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919 Modified by team+...@tracker.debian.org Compiled by team+...@tracker.debian.org Huge version with GTK3 GUI. Features included (+) or not (-): This is the cygwin version: $ gvim --version VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:00:24) Included patches: 1-4372 Modified by Compiled by Huge version with GTK3 GUI. Features included (+) or not (-): I think it's a font issue. The ubunty server just has the bare minimun for X. It's probably just defaulting to the lowest fonts resolution available. > > and the other that looks good is doing, ssh jic@web > > password: > > $ vim w/default.website/Musicos.html > > This latter displays so much clearer and colorful, while the GVim > > under X is ugly, dark and the font is not sharp. Any > > thoughts/suggestions/help would is appreciated. Thanks. > > That is just running on the default remote terminal ...xterm... something. > Check what your ssh is running under, then specify that in your remote > command, before your vim command. Hm... ok. Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty mouse behavior with vim
On 2023-05-18 08:21, Jose Isaias Cabrera via Cygwin wrote: On May 12, 2023 6:23 PM, Jose Isaias Cabrera expressed: On May 12, 2023 12:39 PM, Brian Inglis expressed: If you're running Cygwin/X (installed xinit) you should install Cygwin gvim(/X) for local use and run gvim clients from remote systems on your X server e.g. $ ssh -f -Y ubuntu-remote gvim ... WOW!! THANKS!! I didn't know that one could do this. Works exactly as I wanted. I appreciate it, Brian. So, this is working great, with the exception that the cygwin xterm font display is so much sharper that the GVim display. It's the same .vimrc, but the difference is GVim is from running this command, $ ssh -f -Y jic@web gvim w/default.website/Musicos.html That will depend on the client installed on the remote host! Get them to upgrade to gvim 9 as on Windows ;^> and the other that looks good is doing, ssh jic@web password: $ vim w/default.website/Musicos.html This latter displays so much clearer and colorful, while the GVim under X is ugly, dark and the font is not sharp. Any thoughts/suggestions/help would is appreciated. Thanks. That is just running on the default remote terminal ...xterm... something. Check what your ssh is running under, then specify that in your remote command, before your vim command. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: mintty mouse behavior with vim
Greetings! On May 12, 2023 6:23 PM, Jose Isaias Cabrera expressed: > > > On May 12, 2023 12:39 PM, Brian Inglis expressed: > > > > If you're running Cygwin/X (installed xinit) you should install Cygwin > > gvim(/X) for local use and run gvim clients from remote systems on your X > > server e.g. > > > > $ ssh -f -Y ubuntu-remote gvim ... > > > WOW!! THANKS!! > > I didn't know that one could do this. Works exactly as I wanted. I > appreciate it, Brian. So, this is working great, with the exception that the cygwin xterm font display is so much sharper that the GVim display. It's the same .vimrc, but the difference is GVim is from running this command, $ ssh -f -Y jic@web gvim w/default.website/Musicos.html and the other that looks good is doing, ssh jic@web password: $ vim w/default.website/Musicos.html This latter displays so much clearer and colorful, while the GVim under X is ugly, dark and the font is not sharp. Any thoughts/suggestions/help would is appreciated. Thanks. josé -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: mintty mouse behavior with vim
On May 12, 2023 12:39 PM, Brian Inglis expressed: > > If you're running Cygwin/X (installed xinit) you should install Cygwin > gvim(/X) for local use and run gvim clients from remote systems on your X > server e.g. > > $ ssh -f -Y ubuntu-remote gvim ... > WOW!! THANKS!! I didn't know that one could do this. Works exactly as I wanted. I appreciate it, Brian. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty mouse behavior with vim
On 2023-05-11 12:44, Jose Isaias Cabrera via Cygwin wrote: On May 11, 2023 2:24 PM, Brian Inglis expressed: If I select columns or lines in vim, then the statusline at the bottom of the window shows the number of columns or lines selected before the cursor line and column numbers and percentage thru the file, or the modeline if multiple windows are visible e.g. -- SELECT --4 7,2 All or -- SELECT --4 That's the problem. It's not doing it for me on vim on the cygwin xterm, nor on a connection to an ubuntu server through cygwin mintty. I have gvim for windows, and that works perfectly. But, when I use the cygwin terminal, and an ssh'ed connection to ubuntu, the mouse does not work. I will try to see what are my .vimrc settings for Windows, cygwin and ubuntu and try to match it. I may need to join the vim email support. Thanks. If you're running Cygwin/X (installed xinit) you should install Cygwin gvim(/X) for local use and run gvim clients from remote systems on your X server e.g. $ ssh -f -Y ubuntu-remote gvim ... I moved everything under VIM=$HOME/.vim with VIMRUNTIME=/usr/share/vim/vim82 and cygpath -w equivalent under Windows in the user environment with VIMRUNTIME='C:\Program Files\Vim\vim90', also hardlinks from $HOME to $VIM files, as I used Windows gvim under Cygwin before installing Cygwin/X and gvim, with EDITOR=vim and VISUAL='gvim -f', and still use Windows gvim on the desktop. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: [EXTERNAL] Re: mintty mouse behavior with vim
> > You expect too much of ssh. ssh is a text utility, not an X one. The remote > > vim > > never sees your mouse actions: it's mintty that performs select / paste. > > Are you sure? > > man ssh: > > " -X Enables X11 forwarding. This can also be specified on a > per-host basis in a configuration file." X11 forwarding has nothing to do with mouse tracking on the Cygwin terminal window. Rather, it's a tunnel for the X applications (running on the remote host) that allows them to use a local X11 server (XFree86, XWin32, MobaXTerm etc), which in turn can display the application's window on your PC's desktop (such as an xterm window with the remote host's shell in it) HTH, Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty mouse behavior with vim
On 2023-05-11 20:42, René Berber via Cygwin wrote: On 5/11/2023 8:16 PM, Duncan Roe via Cygwin wrote: You expect too much of ssh. ssh is a text utility, not an X one. The remote vim never sees your mouse actions: it's mintty that performs select / paste. Are you sure? man ssh: " -X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file." In recents decades it is more common to use: -Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty mouse behavior with vim
On 5/11/2023 8:16 PM, Duncan Roe via Cygwin wrote: You expect too much of ssh. ssh is a text utility, not an X one. The remote vim never sees your mouse actions: it's mintty that performs select / paste. Are you sure? man ssh: " -X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file." -- R.B. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty mouse behavior with vim
On Thu, May 11, 2023 at 03:24:18PM +, cygwin wrote: > > Greetings. > > In mintty, while using vim, I would like to highlight a few lines, and > have vim tell me how many lines have been highlighted. Is this a > possibility? For example: > > 0 > 1 > ->2 > ->3 > ->4 > ->5 > 6 > 7 > 8 > 9 > > If I highlight lines 2 through 5, I would like vim to tell me that 4 > lines have been highlighted. It works fine with the windows vim, but it > does not want to do it through mintty. Thoughts? Thanks. > > José > > PS: The real problem is that I am ssh'ing to an ubuntu box which I am > using vim, but the mouse is not being acknowledged. Although, I can > highlight and copy/paste, but clicking to a word to move the cursor > there, it's not acknowledged. > You expect too much of ssh. ssh is a text utility, not an X one. The remote vim never sees your mouse actions: it's mintty that performs select / paste. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty mouse behavior with vim
On 2023-05-11, Jose Isaias Cabrera via Cygwin wrote: > > On May 11, 2023 2:24 PM, Brian Inglis expressed: > > > If I select columns or lines in vim, then the statusline at the > > bottom of the window shows the number of columns or lines > > selected before the cursor line and column numbers and > > percentage thru the file, or the modeline if multiple windows > > are visible e.g. > > > > -- SELECT --4 7,2 All > > or > > -- SELECT --4 > > That's the problem. It's not doing it for me on vim on the cygwin > xterm, nor on a connection to an ubuntu server through cygwin > mintty. I have gvim for windows, and that works perfectly. But, > when I use the cygwin terminal, and an ssh'ed connection to > ubuntu, the mouse does not work. I will try to see what are my > .vimrc settings for Windows, cygwin and ubuntu and try to match > it. I may need to join the vim email support. Thanks. It may be that the 'mouse' option is not set on your Ubuntu vim when using ssh. Try :set mouse=a and see if that works. If not, then check that the version of vim on Ubuntu supports the mouse. Execute :version and check that it is not the tiny or small version and that +mouse and not -mouse appears in the list of features. I know that Ubuntu's standard vim does not support X, but other than that, I don't know what Ubuntu vim package supports what. I always install vim-gtk so I have everything. Regards, Gary -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: mintty mouse behavior with vim
On May 11, 2023 2:24 PM, Brian Inglis expressed: > If I select columns or lines in vim, then the statusline at the bottom of the > window > shows the number of columns or lines selected before the cursor line and > column > numbers and percentage thru the file, or the modeline if multiple windows are > visible e.g. > > -- SELECT -- 4 7,2 All > or > -- SELECT -- 4 That's the problem. It's not doing it for me on vim on the cygwin xterm, nor on a connection to an ubuntu server through cygwin mintty. I have gvim for windows, and that works perfectly. But, when I use the cygwin terminal, and an ssh'ed connection to ubuntu, the mouse does not work. I will try to see what are my .vimrc settings for Windows, cygwin and ubuntu and try to match it. I may need to join the vim email support. Thanks. josé -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty mouse behavior with vim
On 2023-05-11 09:24, Jose Isaias Cabrera via Cygwin wrote: In mintty, while using vim, I would like to highlight a few lines, and have vim tell me how many lines have been highlighted. Is this a possibility? For example: 0 1 ->2 ->3 ->4 ->5 6 7 8 9 If I highlight lines 2 through 5, I would like vim to tell me that 4 lines have been highlighted. It works fine with the windows vim, but it does not want to do it through mintty. Thoughts? Thanks. José PS: The real problem is that I am ssh'ing to an ubuntu box which I am using vim, but the mouse is not being acknowledged. Although, I can highlight and copy/paste, but clicking to a word to move the cursor there, it's not acknowledged. If I select columns or lines in vim, then the statusline at the bottom of the window shows the number of columns or lines selected before the cursor line and column numbers and percentage thru the file, or the modeline if multiple windows are visible e.g. -- SELECT --4 7,2 All or -- SELECT --4 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty terminal crashes after changing the default home via nsswitch.conf and launch in a new profile in Windows 11
Thomas and Brian, Thank you for your replies. > Please also cross-test with another terminal, e.g. rxvt, or xterm (after > running an X server). --- I tried Cygwin/X in the same procedure. I tried only xterm but then I found a clearer problem: After I launch XWin server, I got no response for "Right-clicking on the "X applications menu" icon in the notification area". Also, almost all windows get hung up (no normal response for GUI actions). I can use only keyboard actions to manipulate applications. Of course, again, signout & re-signin solve the problem completely. Once I got some warning message, saying "please contact cygwin developers" or like, but I couldn't reproduce it and I didn't screenshot it... It said "/tmp/... is locked" or something similar. > Are you sure that Windows setup, update, AV update, Edge update, and all the > ... --- The signout & re-signin can be done very quickly, which solves the problem and so I don't think such applications disturbing the environment. Also, I found the issue in my lab, but now testing in my private machine, which is not connected to domain network. Also, I found that to reproduce the mintty terminal hung up, it's better to click the blank (I mean black part) part of the terminal window, not the upper edge of the window. (Then the cursor stops blinking, which is strange.) Yours, Yuta 2023年4月6日(木) 4:55 Brian Inglis : > > On 2023-04-04 20:56, Yuta SUZUKI via Cygwin wrote: > > Thank you for your reply. > > But I can't get the point so much... > > >> This setting example is only a suggestion, not meant to be used verbatim, > >> and > > > --- Yes. In my lab, I use another path for the default home. This is > > just a simple test configuration. > > >> means that, for each Windows account at setup or login, under the user's > >> Windows > >> home directory, you will create a literal "cygwin" subdirectory, to be > >> mounted > > > I think that usually cygwin automatically makes the directory > > assigned as the default home in nsswitch.conf (and indeed it does). > > I tried the same experiment with making C:\Users\test\cygwin manually > > before launching cygwin, but the same crash is reproduced. > > >> When you change this field from the default, it is up to you to understand > >> and support the setting. > > > Well, I know that I want to assign the home directory > > automatically to every user of my lab. > > I don't know the internal structure of cygwin and so what I can do is > > to only announce > > "Do not use cygwin at your very first sign-in to the machine. > > Re-sign-in before launching cygwin". > > But I think this is a bit ridiculous... > > Perhaps wait until account initialization is complete before starting Cygwin > > >> Cygwin startup is probably waiting for an automounter to provide the > >> directory here, > > > Actually, in my experiment, cygwin does make the directory > > C:\Users\test\cygwin > > and even I could output cygcheck to C:\Users\test\cygwin\foo.out (or > > /cygdrive/c/test/foo.out). > > The problem is only in the crash of the window system. > > Addendum: > > Setting Windows environment variable HOME to be /cygdrive/c/users/test > > works without the issue, > > but it does affect another application in my lab as documented in > > cygwin's users guide. > Are you sure that Windows setup, update, AV update, Edge update, and all the > other junk Windows runs has completed, and the account has been logged in, and > that account setup has completed, before you start installing Cygwin, and > before > you start running Cygwin? > > Also be aware that if you are on a domain, to top process in each Cygwin > process > tree has to access the ADC to load up all the AD related info including all > the > group memberships and rights for the user. > This can takes seconds to minutes, if the ADC is not on a close, fast LAN > link. > So wait until you see a Cygwin shell prompt before trying anything. > > Perhaps try with a more lightweight app like cmd, rather than File Explorer, > which easily locks up systems. > Normally switching to TaskMgr, seeing the issue with, and killing the File > Explorer process tree, resets the system, and restarts File Explorer. > > During testing, switch to TaskMgr and check resource usage and waits to see > what > is actually causing the issue. > It is often an app in Cygwin's BLODA Big List Of Dodgy Apps: > > https://cygwin.com/faq/faq.html#faq.using.bloda > > a "dodgy" app, often an AntiVirus, Malware, or other monitor, that is not > written well enough to do its job without interfering with other apps. > > This especially applies to Cygwin as it has to work around Windows limitations > at a low level to implement POSIX compatible syscalls, and AV and monitoring > applications are not always well written. > > Do you have any such software operating on these systems, what is it, is it in > our BLODA list; what is the system resource usage and what is in wait states > when the issue
Re: Mintty terminal crashes after changing the default home via nsswitch.conf and launch in a new profile in Windows 11
On 2023-04-04 20:56, Yuta SUZUKI via Cygwin wrote: Thank you for your reply. But I can't get the point so much... This setting example is only a suggestion, not meant to be used verbatim, and --- Yes. In my lab, I use another path for the default home. This is just a simple test configuration. means that, for each Windows account at setup or login, under the user's Windows home directory, you will create a literal "cygwin" subdirectory, to be mounted I think that usually cygwin automatically makes the directory assigned as the default home in nsswitch.conf (and indeed it does). I tried the same experiment with making C:\Users\test\cygwin manually before launching cygwin, but the same crash is reproduced. When you change this field from the default, it is up to you to understand and support the setting. Well, I know that I want to assign the home directory automatically to every user of my lab. I don't know the internal structure of cygwin and so what I can do is to only announce "Do not use cygwin at your very first sign-in to the machine. Re-sign-in before launching cygwin". But I think this is a bit ridiculous... Perhaps wait until account initialization is complete before starting Cygwin Cygwin startup is probably waiting for an automounter to provide the directory here, Actually, in my experiment, cygwin does make the directory C:\Users\test\cygwin and even I could output cygcheck to C:\Users\test\cygwin\foo.out (or /cygdrive/c/test/foo.out). The problem is only in the crash of the window system. Addendum: Setting Windows environment variable HOME to be /cygdrive/c/users/test works without the issue, but it does affect another application in my lab as documented in cygwin's users guide. Are you sure that Windows setup, update, AV update, Edge update, and all the other junk Windows runs has completed, and the account has been logged in, and that account setup has completed, before you start installing Cygwin, and before you start running Cygwin? Also be aware that if you are on a domain, to top process in each Cygwin process tree has to access the ADC to load up all the AD related info including all the group memberships and rights for the user. This can takes seconds to minutes, if the ADC is not on a close, fast LAN link. So wait until you see a Cygwin shell prompt before trying anything. Perhaps try with a more lightweight app like cmd, rather than File Explorer, which easily locks up systems. Normally switching to TaskMgr, seeing the issue with, and killing the File Explorer process tree, resets the system, and restarts File Explorer. During testing, switch to TaskMgr and check resource usage and waits to see what is actually causing the issue. It is often an app in Cygwin's BLODA Big List Of Dodgy Apps: https://cygwin.com/faq/faq.html#faq.using.bloda a "dodgy" app, often an AntiVirus, Malware, or other monitor, that is not written well enough to do its job without interfering with other apps. This especially applies to Cygwin as it has to work around Windows limitations at a low level to implement POSIX compatible syscalls, and AV and monitoring applications are not always well written. Do you have any such software operating on these systems, what is it, is it in our BLODA list; what is the system resource usage and what is in wait states when the issue occurs? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty terminal crashes after changing the default home via nsswitch.conf and launch in a new profile in Windows 11
Am 04.04.2023 um 17:13 schrieb Yuta SUZUKI via Cygwin: Hi, I am recently setting up the computer room of my faculty and then encountered the following issue: Short description: Change the default home directory via /etc/nsswitch.conf and make a new Windows user. Login to the new user (and do not logout) and launch cygwin. After opening another application's window, e.g. Explorer, and try to switch the focus between the cygwin window and the other window. After once or twice of switch, switching is not smooth and both the cygwin and the other application seem freezing. (Still we can launch powershell to restart the machine.) Procedure to reproduce the issue: 1. Login as an administrator. 2. Install cygwin with the default configuration. 3. In C:\cygwin64\etc\nssswitch.conf, replace # db_home: /home/%U to db_home: /%H/cygwin and save the file. 4. Create a new Windows user, say "test", without Microsoft account. 5. Logout from the administrator user used so far. 6. Login as the user "test". (Do not logout in the remaining steps.) 7. Launch cygwin from the desktop icon. 8. Run cygcheck -s -v -r > cygcheck_before_crash.out (to reproduce the issue, this step is unnecessary.) 9. Open a window of the Explorer. 10. Click the cygwin window. This does not switch the focus to the focus... 11. Click the cygwin icon in the task bar. Probably it switches the window. 12. Run cygcheck -s -v -r > cygcheck_after_crash.out (to reproduce the issue, this step is unnecessary.) 13. Click the Explorer window. This does not switch the focus to the focus... 14. Click the "x" mark on the top right of the cygwin window. This does not close the window... 16. Close the cygwin from the task bar. Probably it closes the window. For me, the behaviour in the step 11, 14, 15 are rather troublesome. If the situation is worse, then I cannot even use the start menu to turn off the machine. In such a case, still I could launch PowerShell with keyboard and run Restart-Computer -Force to restart the machine. Note that if you logout and re-login after the step 6 or if you are using Windows 10, then the issue is not reproduced. Environment: Edition Windows 11 Home Version 22H2 Installed on 3/29/2023 OS build 22621.1413 Experience Windows Feature Experience Pack 1000.22639.1000.0 I attach the above two log files. (Some Japanese is included, sorry: some translations are "なし" = "not applicable" and "ローカル アカウント" = "local account") I would appreciate it very much if someone would solve this issue. Yours, Yuta Suzuki First, the symptoms you describe are not a "crash". Is the terminal actually still responsive (even if with delay)? I cannot reproduce such an issue. Please also cross-test with another terminal, e.g. rxvt, or xterm (after running an X server). Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty terminal crashes after changing the default home via nsswitch.conf and launch in a new profile in Windows 11
Brian,
Thank you for your reply.
But I can't get the point so much...
> This setting example is only a suggestion, not meant to be used verbatim, and
--- Yes. In my lab, I use another path for the default home. This is
just a simple test configuration.
> means that, for each Windows account at setup or login, under the user's
> Windows
> home directory, you will create a literal "cygwin" subdirectory, to be mounted
> ...
I think that usually cygwin automatically makes the directory
assigned as the default home in nsswitch.conf (and indeed it does).
I tried the same experiment with making C:\Users\test\cygwin manually
before launching cygwin,
but the same crash is reproduced.
> When you change this field from the default, it is up to you to understand
> and support the setting.
Well, I know that I want to assign the home directory
automatically to every user of my lab.
I don't know the internal structure of cygwin and so what I can do is
to only announce
"Do not use cygwin at your very first sign-in to the machine.
Re-sign-in before launching cygwin".
But I think this is a bit ridiculous...
> Cygwin startup is probably waiting for an automounter to provide the
> directory here,
Actually, in my experiment, cygwin does make the directory
C:\Users\test\cygwin
and even I could output cygcheck to C:\Users\test\cygwin\foo.out (or
/cygdrive/c/test/foo.out).
The problem is only in the crash of the window system.
Addendum:
Setting Windows environment variable HOME to be /cygdrive/c/users/test
works without the issue,
but it does affect another application in my lab as documented in
cygwin's users guide.
Yours,
Yuta Suzuki
2023年4月5日(水) 4:46 Brian Inglis :
>
> On 2023-04-04 09:13, Yuta SUZUKI via Cygwin wrote:
> > I am recently setting up the computer room of my faculty
> > and then encountered the following issue:
> > Short description:
> > Change the default home directory via
> > /etc/nsswitch.conf
> > and make a new Windows user.
> > Login to the new user (and do not logout) and launch cygwin.
> > After opening another application's window, e.g. Explorer,
> > and try to switch the focus between the cygwin window and the other window.
> > After once or twice of switch, switching is not smooth
> > and both the cygwin and the other application seem freezing.
> > (Still we can launch powershell to restart the machine.)
> > Procedure to reproduce the issue:
> > 1. Login as an administrator.
> > 2. Install cygwin with the default configuration.
> > 3. In C:\cygwin64\etc\nssswitch.conf, replace
> > # db_home: /home/%U
> > to
> > db_home: /%H/cygwin
>
> When you change this field from the default, it is up to you to understand and
> support the setting.
>
> This setting example is only a suggestion, not meant to be used verbatim, and
> means that, for each Windows account at setup or login, under the user's
> Windows
> home directory, you will create a literal "cygwin" subdirectory, to be mounted
> by Cygwin at the user's Cygwin "login" as the user's Cygwin home directory
> /home/$USER.
>
> Cygwin startup is probably waiting for an automounter to provide the directory
> here, just as if this were a Samba, NFS, or Unix network mount, or a Windows
> remote profile mount set up under
> {$USERPROFILE,$HOMEDRIVE$HOMEPATH}/AppData/Remote/.
>
> Given the use of "cygwin" as a schema also here, this is possibly a poor
> example, which could be better documented.
>
> --
> Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
>
> La perfection est atteinte Perfection is achieved
> non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
> mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
> -- Antoine de Saint-Exupéry
--
鈴木 雄太
立教大学 理学部数学科 助教
Yuta Suzuki
Department of Mathematics, Rikkyo University
suzuyu1...@gmail.com
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty terminal crashes after changing the default home via nsswitch.conf and launch in a new profile in Windows 11
On 2023-04-04 09:13, Yuta SUZUKI via Cygwin wrote:
I am recently setting up the computer room of my faculty
and then encountered the following issue:
Short description:
Change the default home directory via
/etc/nsswitch.conf
and make a new Windows user.
Login to the new user (and do not logout) and launch cygwin.
After opening another application's window, e.g. Explorer,
and try to switch the focus between the cygwin window and the other window.
After once or twice of switch, switching is not smooth
and both the cygwin and the other application seem freezing.
(Still we can launch powershell to restart the machine.)
Procedure to reproduce the issue:
1. Login as an administrator.
2. Install cygwin with the default configuration.
3. In C:\cygwin64\etc\nssswitch.conf, replace
# db_home: /home/%U
to
db_home: /%H/cygwin
When you change this field from the default, it is up to you to understand and
support the setting.
This setting example is only a suggestion, not meant to be used verbatim, and
means that, for each Windows account at setup or login, under the user's Windows
home directory, you will create a literal "cygwin" subdirectory, to be mounted
by Cygwin at the user's Cygwin "login" as the user's Cygwin home directory
/home/$USER.
Cygwin startup is probably waiting for an automounter to provide the directory
here, just as if this were a Samba, NFS, or Unix network mount, or a Windows
remote profile mount set up under
{$USERPROFILE,$HOMEDRIVE$HOMEPATH}/AppData/Remote/.
Given the use of "cygwin" as a schema also here, this is possibly a poor
example, which could be better documented.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [mintty] Suppress a key completely
Greetings, Andy Koppe! >> >> Greetings, All! >> >> I'm experimenting with programs to replace my current keyboard switcher >> (which >> is good, but do not behave well with "modern" idiotic applications based on >> Chromium/Electron). >> found one that works nearly exactly as I'd like, but one problem had arisen: >> to implement non-intrusive "CapsLock as keyboard switch" functionality, it >> using native Windows functionality to remap the key to F24, and use that one >> to switch layouts. Everything is good until I launch mintty, where every >> press >> of the key prints "5~" in console in addition to switching the layout. >> I suppose it is in its own right on this one (the key is real, after all), >> but >> is there a way to filter the key so that it does not get down to the >> applications? > Hi Andrey, > I think adding this setting to the .minttyrc should do the job: > KeyFunctions=F24:void Thanks, it worked. > Alternatively, if you get a choice in the matter, you might want to > use the even more obscure yet quite fittingly named VK_SELECT (0x29) > as your switching keycode. Will try that one, too, thank you. Yes, keymapper is quite flexible until you get into OEM (3-byte) key codes. > Also, Windows has the builtin Win+Space combination for switching > keyboards, but I expect you've tried that. My fingers are quite old and don't want to bend like that. -- With best regards, Andrey Repin Wednesday, July 13, 2022 09:45:53 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [mintty] Suppress a key completely
On Sun, 10 Jul 2022 at 15:35, Andrey Repin wrote: > > Greetings, All! > > I'm experimenting with programs to replace my current keyboard switcher (which > is good, but do not behave well with "modern" idiotic applications based on > Chromium/Electron). > found one that works nearly exactly as I'd like, but one problem had arisen: > to implement non-intrusive "CapsLock as keyboard switch" functionality, it > using native Windows functionality to remap the key to F24, and use that one > to switch layouts. Everything is good until I launch mintty, where every press > of the key prints "5~" in console in addition to switching the layout. > I suppose it is in its own right on this one (the key is real, after all), but > is there a way to filter the key so that it does not get down to the > applications? Hi Andrey, I think adding this setting to the .minttyrc should do the job: KeyFunctions=F24:void Alternatively, if you get a choice in the matter, you might want to use the even more obscure yet quite fittingly named VK_SELECT (0x29) as your switching keycode. Also, Windows has the builtin Win+Space combination for switching keyboards, but I expect you've tried that. Regards, Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Sun, May 8, 2022 at 2:09 PM Takashi Yano wrote: > I have pushed two patches to cygwin-3_3-branch. I am not sure > why, but the issue (bash with readline crash) seems to disappear. > > Could you please try? It no longer crashes with these fixes. Thanks! - Orgad -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Sat, 7 May 2022 09:20:51 +0900
Takashi Yano wrote:
> On Sat, 7 May 2022 05:13:23 +0900
> Takashi Yano wrote:
> > On Fri, 6 May 2022 21:16:10 +0200 (CEST)
> > Johannes Schindelin wrote:
> > > Takashi, for the record, I find it hard to believe that the bug is
> > > libreadline's because Orgad's scenario works if he reverts that patch in
> > > the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would
> > > potentially do anything that makes a call to `GetProcessWindowStation()`
> > > not fail but _crash_.
> >
> > I found the following test case also crashes with that commit.
> >
> > 1) Compile rl_stc.c with gcc rl_stc.c -lreadline -o rl_stc.c
> > 2) mintty --hold always ./rl_stc
> >
> > /* rl_stc.c */
> > #include
> > #include
> > #include
> >
> > int main(int argc, char *argv[])
> > {
> > char *str;
> > if (argc > 1) {
> > str = readline(">> ");
> > printf("%s\n", str);
> > free(str);
> > }
> > return 0;
> > }
> >
> > In this test case, no args is specified, so readline() is
> > not called. However, this crashes indeed. This means just
> > loading msys-readline8.dll causes the crash.
>
> 1') gcc --static rl_stc.c -lreadline -lncurses -o rl_stc.c
> 2) mintty --hold always ./rl_stc
>
> also causes crash. In this case, no code from libreadline is
> executed, I think. Why this triggers GetProcessWindowStation()
> crash?
I have pushed two patches to cygwin-3_3-branch. I am not sure
why, but the issue (bash with readline crash) seems to disappear.
Could you please try?
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Sat, 7 May 2022 05:13:23 +0900
Takashi Yano wrote:
> On Fri, 6 May 2022 21:16:10 +0200 (CEST)
> Johannes Schindelin wrote:
> > Takashi, for the record, I find it hard to believe that the bug is
> > libreadline's because Orgad's scenario works if he reverts that patch in
> > the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would
> > potentially do anything that makes a call to `GetProcessWindowStation()`
> > not fail but _crash_.
>
> I found the following test case also crashes with that commit.
>
> 1) Compile rl_stc.c with gcc rl_stc.c -lreadline -o rl_stc.c
> 2) mintty --hold always ./rl_stc
>
> /* rl_stc.c */
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> char *str;
> if (argc > 1) {
> str = readline(">> ");
> printf("%s\n", str);
> free(str);
> }
> return 0;
> }
>
> In this test case, no args is specified, so readline() is
> not called. However, this crashes indeed. This means just
> loading msys-readline8.dll causes the crash.
1') gcc --static rl_stc.c -lreadline -lncurses -o rl_stc.c
2) mintty --hold always ./rl_stc
also causes crash. In this case, no code from libreadline is
executed, I think. Why this triggers GetProcessWindowStation()
crash?
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Fri, 6 May 2022 21:16:10 +0200 (CEST)
Johannes Schindelin wrote:
> Takashi, for the record, I find it hard to believe that the bug is
> libreadline's because Orgad's scenario works if he reverts that patch in
> the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would
> potentially do anything that makes a call to `GetProcessWindowStation()`
> not fail but _crash_.
I found the following test case also crashes with that commit.
1) Compile rl_stc.c with gcc rl_stc.c -lreadline -o rl_stc.c
2) mintty --hold always ./rl_stc
/* rl_stc.c */
#include
#include
#include
int main(int argc, char *argv[])
{
char *str;
if (argc > 1) {
str = readline(">> ");
printf("%s\n", str);
free(str);
}
return 0;
}
In this test case, no args is specified, so readline() is
not called. However, this crashes indeed. This means just
loading msys-readline8.dll causes the crash.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
Hi Orgad, On Fri, 6 May 2022, Orgad Shaneh wrote: > Adding @Johannes Schindelin to the loop. Thank you, but that unfortunately does not work on this list. Due to the policy to never reply-to-all, the subsequent replies immediately lost me. The reason why MSYS2's Bash does not depend on the `libreadline` package is that `bash.exe` is linked _statically_ to that library. Takashi, for the record, I find it hard to believe that the bug is libreadline's because Orgad's scenario works if he reverts that patch in the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would potentially do anything that makes a call to `GetProcessWindowStation()` not fail but _crash_. These console patches sure are gifts that keep on giving. Ciao, Dscho -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Fri, 6 May 2022 17:05:02 +0300 Orgad Shaneh wrote: > On Fri, May 6, 2022 at 1:49 AM Takashi Yano wrote: > > > Only bash in msys2 package fails. > > > > I identified the difference which causes the issue > > between bash built from original source and msys2 bash. > > > > If --enable-readline and --with-installed-readline is specified > > to configure, the problem causes even with bash built from original > > source. > > > > Also, removing --with-installed-readline from configure and removing > > READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves > > the issue. > > > > So it seems to be a readline problem, not a bug in bash itself. > > Adding @Johannes Schindelin to the loop. > > Thanks for your investigation so far. > > So how do we proceed, assuming MSYS project does want to use the > installed readline? I checked the readline PKGBUILD, and it only has > very basic patches, none of them looks suspicious. > > Is (external) readline not used in cygwin/bash? In cygwin the issue does not occur even with bash configured with --enable-readline and --with-installed-readline. > Do you suggest that there's a bug in readline, that your change in the > runtime uncovered? Or is it the other way around? I suspect it's the former. > What might we break if we revert the part I referenced earlier in > fhandler_tty.cc? If you revert that commit, non-cygwin app recieves ctrl-c twice in the following scenario. 1) Start mintty 2) Run cmd.exe 3) Run script command 4) Run non-cygwin app 5) Press ctrl-c This is becase ctrl-c is processed by both mintty pty master and script pty master. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On 2022-05-06 08:05, Orgad Shaneh wrote: On Fri, May 6, 2022 at 1:49 AM Takashi Yano wrote: Only bash in msys2 package fails. I identified the difference which causes the issue between bash built from original source and msys2 bash. If --enable-readline and --with-installed-readline is specified to configure, the problem causes even with bash built from original source. Also, removing --with-installed-readline from configure and removing READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves the issue. So it seems to be a readline problem, not a bug in bash itself. Adding @Johannes Schindelin to the loop. Thanks for your investigation so far. So how do we proceed, assuming MSYS project does want to use the installed readline? I checked the readline PKGBUILD, and it only has very basic patches, none of them looks suspicious. Is (external) readline not used in cygwin/bash? Do you suggest that there's a bug in readline, that your change in the runtime uncovered? Or is it the other way around? What might we break if we revert the part I referenced earlier in fhandler_tty.cc? Cygwin bash and other packages use the latest readline 8.1 library package: $ cygstart https://cygwin.com/packages/summary/readline-src.html $ cygcheck -l libreadline7 /usr/bin/cygreadline7.dll /usr/bin/cyghistory7.dll What readline does MSYS2 bash use - it requires libreadline-devel to build, but does not have any readline dependency, nor is libreadline required by bash: https://packages.msys2.org/package/bash https://packages.msys2.org/package/libreadline -- 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.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Fri, May 6, 2022 at 1:49 AM Takashi Yano wrote: > > Only bash in msys2 package fails. > > I identified the difference which causes the issue > between bash built from original source and msys2 bash. > > If --enable-readline and --with-installed-readline is specified > to configure, the problem causes even with bash built from original > source. > > Also, removing --with-installed-readline from configure and removing > READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves > the issue. > > So it seems to be a readline problem, not a bug in bash itself. Adding @Johannes Schindelin to the loop. Thanks for your investigation so far. So how do we proceed, assuming MSYS project does want to use the installed readline? I checked the readline PKGBUILD, and it only has very basic patches, none of them looks suspicious. Is (external) readline not used in cygwin/bash? Do you suggest that there's a bug in readline, that your change in the runtime uncovered? Or is it the other way around? What might we break if we revert the part I referenced earlier in fhandler_tty.cc? - Orgad -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Thu, 5 May 2022 15:44:40 +0900 Takashi Yano wrote: > On Thu, 5 May 2022 13:41:20 +0900 > Takashi Yano wrote: > > I downloaded bash source files from: > > https://git.savannah.gnu.org/git/bash.git > > and built it by: > > ./configure && make > > and replaced /usr/bin/bash. > > > > Then the issue disappeared. > > Now, I start to suspect the issue is a bug of msys2 bash package. > > I tried several shells and results are as follows. > > tcsh: ok > ash: ok > dash: ok > zsh: ok > ksh: ok > fish: ok > bash (build from original source): ok > > bash (from msys2 package): ng > > Only bash in msys2 package fails. I identified the difference which causes the issue between bash built from original source and msys2 bash. If --enable-readline and --with-installed-readline is specified to configure, the problem causes even with bash built from original source. Also, removing --with-installed-readline from configure and removing READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves the issue. So it seems to be a readline problem, not a bug in bash itself. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Thu, 5 May 2022 13:41:20 +0900 Takashi Yano wrote: > I downloaded bash source files from: > https://git.savannah.gnu.org/git/bash.git > and built it by: > ./configure && make > and replaced /usr/bin/bash. > > Then the issue disappeared. > Now, I start to suspect the issue is a bug of msys2 bash package. I tried several shells and results are as follows. tcsh: ok ash: ok dash: ok zsh: ok ksh: ok fish: ok bash (build from original source): ok bash (from msys2 package): ng Only bash in msys2 package fails. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Thu, 5 May 2022 12:33:07 +0900
Takashi Yano wrote:
> On Thu, 5 May 2022 10:59:54 +0900
> Takashi Yano wrote:
> > On Thu, 5 May 2022 10:27:24 +0900
> > Takashi Yano wrote:
> > > On Thu, 5 May 2022 10:20:45 +0900
> > > Takashi Yano wrote:
> > >
> > > > On Wed, 4 May 2022 16:27:43 +0300
> > > > Orgad Shaneh wrote:
> > > > > On Wed, May 4, 2022 at 2:16 PM Takashi Yano
> > > > > wrote:
> > > > > >
> > > > > > > Reduced the revert to this:
> > > > > > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > > > > > code does not work as expected because it calls Win32
> > > > > > > API directly rather than cygwin read()/write(). Due to
> > > > > > > this behaviour, protection based on attach_mutex does
> > > > > > > not take effect. */
> > > > > > > get_ttyp ()->need_invisible_console = true;
> > > > > > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > > > > > -&& (!get_ttyp ()->invisible_console_pid
> > > > > > > -|| !pinfo (get_ttyp ()->invisible_console_pid)))
> > > > > > > -/* Create a new invisible console for each pty to isolate
> > > > > > > - CTRL_C_EVENTs between ptys. */
> > > > > > > -get_ttyp ()->need_invisible_console = true;
> > > > > > >else
> > > > > > > {
> > > > > > >acquire_attach_mutex (mutex_timeout);
> > > > > > >fhandler_console::need_invisible ();
> > > > > > >release_attach_mutex ();
> > > > > >
> > > > > > A few things about this.
> > > > > >
> > > > > > 1) bash exits with exit code 127 for 'mintty bash'
> > > > > > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh'
> > > > > > work.
> > > > >
> > > > > Right. mintty dash also works.
> > > > >
> > > > > Notice that I did *not* set enable_pcon (not supported on Win7
> > > > > anyway).
> > > >
> > > > Even without that commit (and also with msys2 3.3.4 release),
> > > > something wrong with msys2 in Windows 7.
> > > >
> > > > If you run script command (/usr/bin/script), bash crashes in
> > > > similar way. typescript file generated by script command is
> > > > as follows.
> > > >
> > > > Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin"
> > > > TTY="/dev/cons0" COLUMNS="80" LINES="25"]
> > > >
> > > > Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
> > > >
> > > > bash also exited with exit code 127.
> > >
> > > Ah, this only occurs if script command is started in console.
> >
> > And also this is caused by:
> > get_ttyp ()->need_invisible_console = true;
> > at another place.
>
> I found that bash crashes at:
> h = GetProcessWindowStation ();
> in fhandler_console::need_invisible().
I downloaded bash source files from:
https://git.savannah.gnu.org/git/bash.git
and built it by:
./configure && make
and replaced /usr/bin/bash.
Then the issue disappeared.
Now, I start to suspect the issue is a bug of msys2 bash package.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Thu, 5 May 2022 10:59:54 +0900
Takashi Yano wrote:
> On Thu, 5 May 2022 10:27:24 +0900
> Takashi Yano wrote:
> > On Thu, 5 May 2022 10:20:45 +0900
> > Takashi Yano wrote:
> >
> > > On Wed, 4 May 2022 16:27:43 +0300
> > > Orgad Shaneh wrote:
> > > > On Wed, May 4, 2022 at 2:16 PM Takashi Yano
> > > > wrote:
> > > > >
> > > > > > Reduced the revert to this:
> > > > > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > > > > code does not work as expected because it calls Win32
> > > > > > API directly rather than cygwin read()/write(). Due to
> > > > > > this behaviour, protection based on attach_mutex does
> > > > > > not take effect. */
> > > > > > get_ttyp ()->need_invisible_console = true;
> > > > > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > > > > -&& (!get_ttyp ()->invisible_console_pid
> > > > > > -|| !pinfo (get_ttyp ()->invisible_console_pid)))
> > > > > > -/* Create a new invisible console for each pty to isolate
> > > > > > - CTRL_C_EVENTs between ptys. */
> > > > > > -get_ttyp ()->need_invisible_console = true;
> > > > > >else
> > > > > > {
> > > > > >acquire_attach_mutex (mutex_timeout);
> > > > > >fhandler_console::need_invisible ();
> > > > > >release_attach_mutex ();
> > > > >
> > > > > A few things about this.
> > > > >
> > > > > 1) bash exits with exit code 127 for 'mintty bash'
> > > > > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh'
> > > > > work.
> > > >
> > > > Right. mintty dash also works.
> > > >
> > > > Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
> > >
> > > Even without that commit (and also with msys2 3.3.4 release),
> > > something wrong with msys2 in Windows 7.
> > >
> > > If you run script command (/usr/bin/script), bash crashes in
> > > similar way. typescript file generated by script command is
> > > as follows.
> > >
> > > Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin"
> > > TTY="/dev/cons0" COLUMNS="80" LINES="25"]
> > >
> > > Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
> > >
> > > bash also exited with exit code 127.
> >
> > Ah, this only occurs if script command is started in console.
>
> And also this is caused by:
> get_ttyp ()->need_invisible_console = true;
> at another place.
I found that bash crashes at:
h = GetProcessWindowStation ();
in fhandler_console::need_invisible().
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Thu, 5 May 2022 10:27:24 +0900
Takashi Yano wrote:
> On Thu, 5 May 2022 10:20:45 +0900
> Takashi Yano wrote:
>
> > On Wed, 4 May 2022 16:27:43 +0300
> > Orgad Shaneh wrote:
> > > On Wed, May 4, 2022 at 2:16 PM Takashi Yano
> > > wrote:
> > > >
> > > > > Reduced the revert to this:
> > > > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > > > code does not work as expected because it calls Win32
> > > > > API directly rather than cygwin read()/write(). Due to
> > > > > this behaviour, protection based on attach_mutex does
> > > > > not take effect. */
> > > > > get_ttyp ()->need_invisible_console = true;
> > > > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > > > -&& (!get_ttyp ()->invisible_console_pid
> > > > > -|| !pinfo (get_ttyp ()->invisible_console_pid)))
> > > > > -/* Create a new invisible console for each pty to isolate
> > > > > - CTRL_C_EVENTs between ptys. */
> > > > > -get_ttyp ()->need_invisible_console = true;
> > > > >else
> > > > > {
> > > > >acquire_attach_mutex (mutex_timeout);
> > > > >fhandler_console::need_invisible ();
> > > > >release_attach_mutex ();
> > > >
> > > > A few things about this.
> > > >
> > > > 1) bash exits with exit code 127 for 'mintty bash'
> > > > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
> > >
> > > Right. mintty dash also works.
> > >
> > > Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
> >
> > Even without that commit (and also with msys2 3.3.4 release),
> > something wrong with msys2 in Windows 7.
> >
> > If you run script command (/usr/bin/script), bash crashes in
> > similar way. typescript file generated by script command is
> > as follows.
> >
> > Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin" TTY="/dev/cons0"
> > COLUMNS="80" LINES="25"]
> >
> > Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
> >
> > bash also exited with exit code 127.
>
> Ah, this only occurs if script command is started in console.
And also this is caused by:
get_ttyp ()->need_invisible_console = true;
at another place.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Thu, 5 May 2022 10:20:45 +0900
Takashi Yano wrote:
> On Wed, 4 May 2022 16:27:43 +0300
> Orgad Shaneh wrote:
> > On Wed, May 4, 2022 at 2:16 PM Takashi Yano
> > wrote:
> > >
> > > > Reduced the revert to this:
> > > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > > code does not work as expected because it calls Win32
> > > > API directly rather than cygwin read()/write(). Due to
> > > > this behaviour, protection based on attach_mutex does
> > > > not take effect. */
> > > > get_ttyp ()->need_invisible_console = true;
> > > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > > -&& (!get_ttyp ()->invisible_console_pid
> > > > -|| !pinfo (get_ttyp ()->invisible_console_pid)))
> > > > -/* Create a new invisible console for each pty to isolate
> > > > - CTRL_C_EVENTs between ptys. */
> > > > -get_ttyp ()->need_invisible_console = true;
> > > >else
> > > > {
> > > >acquire_attach_mutex (mutex_timeout);
> > > >fhandler_console::need_invisible ();
> > > >release_attach_mutex ();
> > >
> > > A few things about this.
> > >
> > > 1) bash exits with exit code 127 for 'mintty bash'
> > > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
> >
> > Right. mintty dash also works.
> >
> > Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
>
> Even without that commit (and also with msys2 3.3.4 release),
> something wrong with msys2 in Windows 7.
>
> If you run script command (/usr/bin/script), bash crashes in
> similar way. typescript file generated by script command is
> as follows.
>
> Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin" TTY="/dev/cons0"
> COLUMNS="80" LINES="25"]
>
> Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
>
> bash also exited with exit code 127.
Ah, this only occurs if script command is started in console.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Wed, 4 May 2022 16:27:43 +0300
Orgad Shaneh wrote:
> On Wed, May 4, 2022 at 2:16 PM Takashi Yano wrote:
> >
> > > Reduced the revert to this:
> > > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > > code does not work as expected because it calls Win32
> > > API directly rather than cygwin read()/write(). Due to
> > > this behaviour, protection based on attach_mutex does
> > > not take effect. */
> > > get_ttyp ()->need_invisible_console = true;
> > > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > > -&& (!get_ttyp ()->invisible_console_pid
> > > -|| !pinfo (get_ttyp ()->invisible_console_pid)))
> > > -/* Create a new invisible console for each pty to isolate
> > > - CTRL_C_EVENTs between ptys. */
> > > -get_ttyp ()->need_invisible_console = true;
> > >else
> > > {
> > >acquire_attach_mutex (mutex_timeout);
> > >fhandler_console::need_invisible ();
> > >release_attach_mutex ();
> >
> > A few things about this.
> >
> > 1) bash exits with exit code 127 for 'mintty bash'
> > 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
>
> Right. mintty dash also works.
>
> Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
Even without that commit (and also with msys2 3.3.4 release),
something wrong with msys2 in Windows 7.
If you run script command (/usr/bin/script), bash crashes in
similar way. typescript file generated by script command is
as follows.
Script started on 2022-05-05 10:12:28+09:00 [TERM="cygwin" TTY="/dev/cons0"
COLUMNS="80" LINES="25"]
Script done on 2022-05-05 10:12:29+09:00 [COMMAND_EXIT_CODE="127"]
bash also exited with exit code 127.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: [cygwin] Re: mintty phantom key presses
> -Original Message- > From: Eric Adams > Sent: Wednesday, May 4, 2022 1:58 PM > > On Tue, May 3, 2022 at 9:27 AM Jason Pyeron wrote: > > > > Does it happen on a fresh install (you can use another directory). I am > > interested because I have > observed similar, but different, control code weirdness. > > > > v/r, > > Jason > > > > Jason, > I think I installed a fresh minimalist copy at C:\cygwin64TEST, went > into the bin directory and invoked mintty. > Within the new mintty, I started vi, and performed the vi insertion > test. I did not find escape characters inserted. Glad to hear there is a configuration that does not cause a problem. > > I would try to note differences from my typical environment - a new > binary directory / mintty invoked from the bin directory I usually copy the cygterm shortcut and update for the new root path and name - I am lazy. > / running > bash instead of tcsh / I think the home directory was the same / not > all startup files were found or used / I felt very strange in this > setup :) . Start looking at input rc related things? Try to make the new match the old... testing along the way. diff -urw is your friend. -Jason -- Jason Pyeron | Architect PD Inc| Certified SBA 8(a) 10 w 24th St | Certified SBA HUBZone Baltimore, MD | CAGE Code: 1WVR6 .mil: jason.j.pyeron@mail.mil .com: jpye...@pdinc.us tel : 202-741-9397 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [cygwin] Re: mintty phantom key presses
On Tue, May 3, 2022 at 9:27 AM Jason Pyeron wrote: > > Does it happen on a fresh install (you can use another directory). I am > interested because I have observed similar, but different, control code > weirdness. > > v/r, > Jason > Jason, I think I installed a fresh minimalist copy at C:\cygwin64TEST, went into the bin directory and invoked mintty. Within the new mintty, I started vi, and performed the vi insertion test. I did not find escape characters inserted. I would try to note differences from my typical environment - a new binary directory / mintty invoked from the bin directory / running bash instead of tcsh / I think the home directory was the same / not all startup files were found or used / I felt very strange in this setup :) . Eric Adams. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Wed, May 4, 2022 at 2:16 PM Takashi Yano wrote:
>
> > Reduced the revert to this:
> > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > code does not work as expected because it calls Win32
> > API directly rather than cygwin read()/write(). Due to
> > this behaviour, protection based on attach_mutex does
> > not take effect. */
> > get_ttyp ()->need_invisible_console = true;
> > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > -&& (!get_ttyp ()->invisible_console_pid
> > -|| !pinfo (get_ttyp ()->invisible_console_pid)))
> > -/* Create a new invisible console for each pty to isolate
> > - CTRL_C_EVENTs between ptys. */
> > -get_ttyp ()->need_invisible_console = true;
> >else
> > {
> >acquire_attach_mutex (mutex_timeout);
> >fhandler_console::need_invisible ();
> >release_attach_mutex ();
>
> A few things about this.
>
> 1) bash exits with exit code 127 for 'mintty bash'
> 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
Right. mintty dash also works.
Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
- Orgad
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Wed, 4 May 2022 12:46:28 +0300
Orgad Shaneh wrote:
> On Wed, May 4, 2022 at 12:33 PM Orgad Shaneh wrote:
> >
> > On Tue, May 3, 2022 at 7:10 PM Takashi Yano
> > wrote:
> > >
> > > On Tue, 3 May 2022 18:52:28 +0300
> > > Orgad Shaneh wrote:
> > > > On Tue, May 3, 2022 at 6:23 PM Takashi Yano
> > > > wrote:
> > > > >
> > > > > On Tue, 3 May 2022 14:47:17 +0300
> > > > > Orgad Shaneh wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
> > > > > >
> > > > > > Tested in MSYS2 on merge-3.3 branch from
> > > > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of
> > > > > > cygwin-3_3-branch as of today (05827d2df8).
> > > > > >
> > > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
> > > > > Is this MSYS2 specific problem?
> > > >
> > > > You're right. I can't reproduce either. Only in my MSYS branch.
> > > >
> > > > Can you give me some guidance how to debug it?
> > >
> > > If you could identify which commit causes the issue, It would help.
> >
> > 0e1847fb87f5306cda6c022540560c5926627ae1 is the first bad commit
> > commit 0e1847fb87f5306cda6c022540560c5926627ae1
> > Author: Takashi Yano
> > Date: Mon Feb 28 20:25:09 2022 +0900
> >
> > Cygwin: pty: Isolate CTRL_C_EVENTs between ptys.
> >
> > - With this patch, unique invisible consoles are created for each pty
> > to isolate CTRL_C_EVENTs between ptys. This is necessary by Ctrl-C
> > handling in fhandler_termios::process_sigs() for non-cygwin apps
> > started in pty if the pseudo console is disabled.
> >
> > winsup/cygwin/fhandler_termios.cc | 6 ++
> > winsup/cygwin/fhandler_tty.cc | 17 +
> > winsup/cygwin/tty.cc | 2 ++
> > 3 files changed, 21 insertions(+), 4 deletions(-)
> >
> > I tried reverting this commit, and it fixed the crash indeed.
> >
> > - Orgad
>
> Reduced the revert to this:
> @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> code does not work as expected because it calls Win32
> API directly rather than cygwin read()/write(). Due to
> this behaviour, protection based on attach_mutex does
> not take effect. */
> get_ttyp ()->need_invisible_console = true;
> - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> -&& (!get_ttyp ()->invisible_console_pid
> -|| !pinfo (get_ttyp ()->invisible_console_pid)))
> -/* Create a new invisible console for each pty to isolate
> - CTRL_C_EVENTs between ptys. */
> -get_ttyp ()->need_invisible_console = true;
>else
> {
>acquire_attach_mutex (mutex_timeout);
>fhandler_console::need_invisible ();
>release_attach_mutex ();
A few things about this.
1) bash exits with exit code 127 for 'mintty bash'
2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Wed, May 4, 2022 at 12:33 PM Orgad Shaneh wrote:
>
> On Tue, May 3, 2022 at 7:10 PM Takashi Yano wrote:
> >
> > On Tue, 3 May 2022 18:52:28 +0300
> > Orgad Shaneh wrote:
> > > On Tue, May 3, 2022 at 6:23 PM Takashi Yano
> > > wrote:
> > > >
> > > > On Tue, 3 May 2022 14:47:17 +0300
> > > > Orgad Shaneh wrote:
> > > > > Hi,
> > > > >
> > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
> > > > >
> > > > > Tested in MSYS2 on merge-3.3 branch from
> > > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of
> > > > > cygwin-3_3-branch as of today (05827d2df8).
> > > > >
> > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
> > > > Is this MSYS2 specific problem?
> > >
> > > You're right. I can't reproduce either. Only in my MSYS branch.
> > >
> > > Can you give me some guidance how to debug it?
> >
> > If you could identify which commit causes the issue, It would help.
>
> 0e1847fb87f5306cda6c022540560c5926627ae1 is the first bad commit
> commit 0e1847fb87f5306cda6c022540560c5926627ae1
> Author: Takashi Yano
> Date: Mon Feb 28 20:25:09 2022 +0900
>
> Cygwin: pty: Isolate CTRL_C_EVENTs between ptys.
>
> - With this patch, unique invisible consoles are created for each pty
> to isolate CTRL_C_EVENTs between ptys. This is necessary by Ctrl-C
> handling in fhandler_termios::process_sigs() for non-cygwin apps
> started in pty if the pseudo console is disabled.
>
> winsup/cygwin/fhandler_termios.cc | 6 ++
> winsup/cygwin/fhandler_tty.cc | 17 +
> winsup/cygwin/tty.cc | 2 ++
> 3 files changed, 21 insertions(+), 4 deletions(-)
>
> I tried reverting this commit, and it fixed the crash indeed.
>
> - Orgad
Reduced the revert to this:
@@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
code does not work as expected because it calls Win32
API directly rather than cygwin read()/write(). Due to
this behaviour, protection based on attach_mutex does
not take effect. */
get_ttyp ()->need_invisible_console = true;
- else if (_major (myself->ctty) != DEV_CONS_MAJOR
-&& (!get_ttyp ()->invisible_console_pid
-|| !pinfo (get_ttyp ()->invisible_console_pid)))
-/* Create a new invisible console for each pty to isolate
- CTRL_C_EVENTs between ptys. */
-get_ttyp ()->need_invisible_console = true;
else
{
acquire_attach_mutex (mutex_timeout);
fhandler_console::need_invisible ();
release_attach_mutex ();
- Orgad
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Tue, May 3, 2022 at 7:10 PM Takashi Yano wrote: > > On Tue, 3 May 2022 18:52:28 +0300 > Orgad Shaneh wrote: > > On Tue, May 3, 2022 at 6:23 PM Takashi Yano > > wrote: > > > > > > On Tue, 3 May 2022 14:47:17 +0300 > > > Orgad Shaneh wrote: > > > > Hi, > > > > > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch. > > > > > > > > Tested in MSYS2 on merge-3.3 branch from > > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of > > > > cygwin-3_3-branch as of today (05827d2df8). > > > > > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch. > > > Is this MSYS2 specific problem? > > > > You're right. I can't reproduce either. Only in my MSYS branch. > > > > Can you give me some guidance how to debug it? > > If you could identify which commit causes the issue, It would help. 0e1847fb87f5306cda6c022540560c5926627ae1 is the first bad commit commit 0e1847fb87f5306cda6c022540560c5926627ae1 Author: Takashi Yano Date: Mon Feb 28 20:25:09 2022 +0900 Cygwin: pty: Isolate CTRL_C_EVENTs between ptys. - With this patch, unique invisible consoles are created for each pty to isolate CTRL_C_EVENTs between ptys. This is necessary by Ctrl-C handling in fhandler_termios::process_sigs() for non-cygwin apps started in pty if the pseudo console is disabled. winsup/cygwin/fhandler_termios.cc | 6 ++ winsup/cygwin/fhandler_tty.cc | 17 + winsup/cygwin/tty.cc | 2 ++ 3 files changed, 21 insertions(+), 4 deletions(-) I tried reverting this commit, and it fixed the crash indeed. - Orgad -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Tue, 3 May 2022 18:52:28 +0300 Orgad Shaneh wrote: > On Tue, May 3, 2022 at 6:23 PM Takashi Yano wrote: > > > > On Tue, 3 May 2022 14:47:17 +0300 > > Orgad Shaneh wrote: > > > Hi, > > > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch. > > > > > > Tested in MSYS2 on merge-3.3 branch from > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of > > > cygwin-3_3-branch as of today (05827d2df8). > > > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch. > > Is this MSYS2 specific problem? > > You're right. I can't reproduce either. Only in my MSYS branch. > > Can you give me some guidance how to debug it? If you could identify which commit causes the issue, It would help. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Tue, May 3, 2022 at 6:23 PM Takashi Yano wrote: > > On Tue, 3 May 2022 14:47:17 +0300 > Orgad Shaneh wrote: > > Hi, > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch. > > > > Tested in MSYS2 on merge-3.3 branch from > > https://github.com/orgads/msys2-runtime-1. It includes the tip of > > cygwin-3_3-branch as of today (05827d2df8). > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch. > Is this MSYS2 specific problem? You're right. I can't reproduce either. Only in my MSYS branch. Can you give me some guidance how to debug it? - Orgad -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty crashes on Windows 7
On Tue, 3 May 2022 14:47:17 +0300 Orgad Shaneh wrote: > Hi, > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch. > > Tested in MSYS2 on merge-3.3 branch from > https://github.com/orgads/msys2-runtime-1. It includes the tip of > cygwin-3_3-branch as of today (05827d2df8). > > Steps to reproduce: > 1. Start cmd.exe > 2. cd \usr\bin > 3. mintty ./bash > > GDB trace attached. Simplified form: > > 1 ntdll!KiRaiseUserExceptionDispatcher 0x7791b5ba > 2 KERNELBASE!CloseHandle 0x7feffb31863 > 3 KERNEL32!CloseHandle 0x776b14f1 > 4 fhandler_base::close fhandler.cc 1217 0x1800682db > 5 fhandler_pipe::close fhandler_pipe.cc 685 0x18009069a > 6 fhandler_base::close_with_arch fhandler.cc 1193 0x18006c7d5 > 7 close_all_files syscalls.cc 102 0x18014548f > 8 do_exit dcrt0.cc 1200 0x180048213 > 9 _exitdcrt0.cc 1317 0x1800483ef > 10 exit exit.c 64 0x1801b3bdd > 11 cygwin_exit dcrt0.cc 1311 0x1800483d3 > 12 _sigfe sigfe.s 35 0x18019593b > 13 ?? I cannot reproduce this with cygwin git head of cygwin-3_3-branch. Is this MSYS2 specific problem? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: [cygwin] Re: mintty phantom key presses
> -Original Message- > From: Thomas Wolff > Sent: Tuesday, May 3, 2022 10:02 AM > > > Am 03.05.2022 um 14:26 schrieb Eric Adams: > > On Tue, May 3, 2022 at 6:53 AM Thomas Wolff wrote: > > I don't have any local vim customization files, my user minttyrc and > > tcshrc files are attached. > > > > Thanks again, > > Eric Adams. > I do not reproduce such issue, there must be something weird configured > in your environment. Does it happen on a fresh install (you can use another directory). I am interested because I have observed similar, but different, control code weirdness. v/r, Jason -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty phantom key presses
Am 03.05.2022 um 14:26 schrieb Eric Adams: On Tue, May 3, 2022 at 6:53 AM Thomas Wolff wrote: Am 03/05/2022 um 13:50 schrieb Eric Adams: On Tue, May 3, 2022 at 12:20 AM Thomas Wolff wrote: Am 02.05.2022 um 23:54 schrieb Eric Adams: Hi, I had previously reported this issue as "Possible phantom control-key state..." I observe that moving between cygwin mintty windows and Windows windows causes unexpected behavior in the cygwin world. I took a new approach, using vi :) . In cygwin, I open a new file, enter insert mode, hit Ctrl-V, and mouse out of the window. When I mouse back into the cygwin edit window, my screen contains the display string "^[[O" (note that the "^[" is vi-speak for "esc"). Examining the resulting file with od shows: od -ah fdsa 000 esc [ O nl 5b1b0a4f Here, the nl character is inserted by vi. This smells like an incomplete escape sequence. If it's left at the command line, just waiting for the user to type something, there might be trouble. Am I completely off? Thanks, Eric Adams. CSI O is the focus off notification (CSI I is the focus in notification). Someone has switched on focus reporting mode (CSI ? 1004 h) in your session (and isn't catching the notifications). Run your application in a fresh mintty, with no other software, to test. Thomas Thomas, Thank you for your insight. I'm afraid I don't know how to test this without some extra software involved. In a fresh mintty, I tried "cat - > capturefile", focussed in and out of the window a few times and hit Ctrl-D. The capturefile was empty. In a new mintty window, I try the vi experiment, and the escape sequence is captured. Suggestions? Thank you, Eric Adams. Which system do you run? (cygwin, msys) Is that cygwin vi? (What does `type vi` say?) What are your bash/vi configuration files? Thank you again. I'm running a cygwin system, with cygwin tcsh shell and cygwin vi. LAPTOP-2LPUB1MQ:~ 54> which vi vi: aliased to vim LAPTOP-2LPUB1MQ:~ 55> which vim /usr/bin/vim I don't have any local vim customization files, my user minttyrc and tcshrc files are attached. Thanks again, Eric Adams. I do not reproduce such issue, there must be something weird configured in your environment. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty phantom key presses
On Tue, May 3, 2022 at 6:53 AM Thomas Wolff wrote: > > > Am 03/05/2022 um 13:50 schrieb Eric Adams: > > On Tue, May 3, 2022 at 12:20 AM Thomas Wolff wrote: > >> Am 02.05.2022 um 23:54 schrieb Eric Adams: > >>> Hi, > >>> > >>> I had previously reported this issue as "Possible phantom control-key > >>> state..." > >>> > >>> I observe that moving between cygwin mintty windows and Windows > >>> windows causes unexpected behavior in the cygwin world. > >>> > >>> I took a new approach, using vi :) . In cygwin, I open a new file, > >>> enter insert mode, hit Ctrl-V, and mouse out of the window. When I > >>> mouse back into the cygwin edit window, my screen contains the display > >>> string "^[[O" (note that the "^[" is vi-speak for "esc"). Examining > >>> the resulting file with od shows: > od -ah fdsa > >>> 000 esc [ O nl > >>> 5b1b0a4f > >>> > >>> Here, the nl character is inserted by vi. > >>> > >>> This smells like an incomplete escape sequence. If it's left at the > >>> command line, just waiting for the user to type something, there might > >>> be trouble. > >>> > >>> Am I completely off? > >>> Thanks, > >>> Eric Adams. > >> CSI O is the focus off notification (CSI I is the focus in notification). > >> Someone has switched on focus reporting mode (CSI ? 1004 h) in your > >> session (and isn't catching the notifications). > >> Run your application in a fresh mintty, with no other software, to test. > >> Thomas > >> > > Thomas, > > Thank you for your insight. I'm afraid I don't know how to test this > > without some extra software involved. > > > > In a fresh mintty, I tried "cat - > capturefile", focussed in and out > > of the window a few times and hit Ctrl-D. The capturefile was empty. > > > > In a new mintty window, I try the vi experiment, and the escape > > sequence is captured. > > > > Suggestions? > > > > Thank you, > > Eric Adams. > Which system do you run? (cygwin, msys) > Is that cygwin vi? (What does `type vi` say?) > What are your bash/vi configuration files? Thank you again. I'm running a cygwin system, with cygwin tcsh shell and cygwin vi. LAPTOP-2LPUB1MQ:~ 54> which vi vi: aliased to vim LAPTOP-2LPUB1MQ:~ 55> which vim /usr/bin/vim I don't have any local vim customization files, my user minttyrc and tcshrc files are attached. Thanks again, Eric Adams. adams.minttyrc Description: Binary data adams.tcshrc Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty phantom key presses
Am 03/05/2022 um 13:50 schrieb Eric Adams: On Tue, May 3, 2022 at 12:20 AM Thomas Wolff wrote: Am 02.05.2022 um 23:54 schrieb Eric Adams: Hi, I had previously reported this issue as "Possible phantom control-key state..." I observe that moving between cygwin mintty windows and Windows windows causes unexpected behavior in the cygwin world. I took a new approach, using vi :) . In cygwin, I open a new file, enter insert mode, hit Ctrl-V, and mouse out of the window. When I mouse back into the cygwin edit window, my screen contains the display string "^[[O" (note that the "^[" is vi-speak for "esc"). Examining the resulting file with od shows: od -ah fdsa 000 esc [ O nl 5b1b0a4f Here, the nl character is inserted by vi. This smells like an incomplete escape sequence. If it's left at the command line, just waiting for the user to type something, there might be trouble. Am I completely off? Thanks, Eric Adams. CSI O is the focus off notification (CSI I is the focus in notification). Someone has switched on focus reporting mode (CSI ? 1004 h) in your session (and isn't catching the notifications). Run your application in a fresh mintty, with no other software, to test. Thomas Thomas, Thank you for your insight. I'm afraid I don't know how to test this without some extra software involved. In a fresh mintty, I tried "cat - > capturefile", focussed in and out of the window a few times and hit Ctrl-D. The capturefile was empty. In a new mintty window, I try the vi experiment, and the escape sequence is captured. Suggestions? Thank you, Eric Adams. Which system do you run? (cygwin, msys) Is that cygwin vi? (What does `type vi` say?) What are your bash/vi configuration files? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty phantom key presses
On Tue, May 3, 2022 at 12:20 AM Thomas Wolff wrote: > > Am 02.05.2022 um 23:54 schrieb Eric Adams: > > Hi, > > > > I had previously reported this issue as "Possible phantom control-key > > state..." > > > > I observe that moving between cygwin mintty windows and Windows > > windows causes unexpected behavior in the cygwin world. > > > > I took a new approach, using vi :) . In cygwin, I open a new file, > > enter insert mode, hit Ctrl-V, and mouse out of the window. When I > > mouse back into the cygwin edit window, my screen contains the display > > string "^[[O" (note that the "^[" is vi-speak for "esc"). Examining > > the resulting file with od shows: > >> od -ah fdsa > > 000 esc [ O nl > > 5b1b0a4f > > > > Here, the nl character is inserted by vi. > > > > This smells like an incomplete escape sequence. If it's left at the > > command line, just waiting for the user to type something, there might > > be trouble. > > > > Am I completely off? > > Thanks, > > Eric Adams. > CSI O is the focus off notification (CSI I is the focus in notification). > Someone has switched on focus reporting mode (CSI ? 1004 h) in your > session (and isn't catching the notifications). > Run your application in a fresh mintty, with no other software, to test. > Thomas > Thomas, Thank you for your insight. I'm afraid I don't know how to test this without some extra software involved. In a fresh mintty, I tried "cat - > capturefile", focussed in and out of the window a few times and hit Ctrl-D. The capturefile was empty. In a new mintty window, I try the vi experiment, and the escape sequence is captured. Suggestions? Thank you, Eric Adams. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty phantom key presses
Am 02.05.2022 um 23:54 schrieb Eric Adams: Hi, I had previously reported this issue as "Possible phantom control-key state..." I observe that moving between cygwin mintty windows and Windows windows causes unexpected behavior in the cygwin world. I took a new approach, using vi :) . In cygwin, I open a new file, enter insert mode, hit Ctrl-V, and mouse out of the window. When I mouse back into the cygwin edit window, my screen contains the display string "^[[O" (note that the "^[" is vi-speak for "esc"). Examining the resulting file with od shows: od -ah fdsa 000 esc [ O nl 5b1b0a4f Here, the nl character is inserted by vi. This smells like an incomplete escape sequence. If it's left at the command line, just waiting for the user to type something, there might be trouble. Am I completely off? Thanks, Eric Adams. CSI O is the focus off notification (CSI I is the focus in notification). Someone has switched on focus reporting mode (CSI ? 1004 h) in your session (and isn't catching the notifications). Run your application in a fresh mintty, with no other software, to test. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty 3.5.1-1: -p center no longer works
Am 08.11.2021 um 01:04 schrieb Bryan Higgins: mintty 3.5.1-1: -p center no longer works. Reverted to 3.5.0, which is fine.: Yeah, this is already fixed for 3.5.2, to be released in a few days. (Actually, it didn't work properly in 3.5.0 and before already on high-DPI monitors.) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty overstrokes some fonts unexpectedly
On Mon, 26 Apr 2021 20:31:38 +0200, Thomas Wolff > > Am 26.04.2021 um 01:14 schrieb Lemures Lemniscati via Cygwin: > > On Sun, 25 Apr 2021 22:33:57 +0200, Thomas Wolff > >> Am 25.04.2021 um 15:41 schrieb Lemures Lemniscati via Cygwin: > >>> Hi! > >>> > >>> mintty overstrokes some fonts unexpectedly. > >>> https://gitlab.com/test.cases/mintty-test/-/tree/54ae800e695ecd1741851cab57320a9d0e95a6fd > >>> > >>> I got a result mintty-sample-msgothic.png. > >>> https://gitlab.com/test.cases/mintty-test/-/blob/54ae800e695ecd1741851cab57320a9d0e95a6fd/mintty-sample-msgothic.png > >>> > >>> In the 4th line of the output, fonts (of u+25cb) were overstruck > >>> unexpectedly. > >>> And there are other characters also, which are similarly overstruck. > >> This is a Windows bug. Mintty clearly instruct Windows to apply > >> equidistant spacing to achieve fixed-width character cell behaviour. But > >> for certain character ranges, Windows ignores that. Another example for > >> such misbehaviour is the Tibetan block (U+0F00-U+0FFF). Mintty could work > >> around that by rendering characters separately, at a significant penalty > >> for output speed however. Or it could do that only for affected ranges, > >> but criteria to identify them are obscure. > > Thank you, Thomas. > > > > I tried some earlier versions of mintty: > > > > * mintty-3.1.0-1 has the same issue > > * mintty-2.9.6-0 works expectedly in this case. > My previous comment was wrong, sorry. The cause of the issue is that the > Windows CJK fonts are designed for CJK ambiguous-wide layout. If you run > mintty with option Charwidth=ambig-wide, or better in an ambiguous-wide > locale like LC_CTYPE=C.utf8@cjkwide, width handling and font rendering will > match. > Mintty applies auto-narrowing to some characters that would render far out of > their character cell, squeezing them into the cell, in order to optimise the > trade-off between readability and authentic rendering. > Some character ranges were taken out of that mechanism in 2.9.7, including > the Geometric Shapes which you've encountered, in this case because they are > "geometric" and the assumption was that they should not be tampered for > rendering. Thank you, Thomas! I overlooked 'man mintty'. It works expectedly under the setting. I'd be happy if the option Charwidth is accessible from GUI. Regards, Lem -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
On 4/25/2021 5:15 PM, Mark Geisert wrote: Jim Garrison via Cygwin wrote: Mintty's window does not seem to have any border at the left and bottom. The top of the window has the title menu bar and the right side is the scroll bar. When I have multiple mintty windows open, and they overlap, since there is no border, one window blends into another. I searched mintty's options and there doesn't seem to be a way to specify a border. If the window background is a light color, there's a subtle drop shadow that helps a bit, but with a dark style it's impossible to distinguish the windows. Here's a sample: https://drive.google.com/file/d/10zKWdie_nA-_hzsN8i_GeCw7VadJBmol/view?usp=sharing Is there a way to make it draw a border? As Thomas pointed out, not mintty's fault. I ran into the same issue on first upgrade to Windows 10. Windows 7 allowed one to set window borders; Windows 8 and up don't. But one can adjust registry entries to fix the issue. Check here: https://www.thewindowsclub.com/change-desktop-windows-metrics-border-width-windows-8 The fix outlined there works for Windows 10 too. HTH, ..mark Perfect, that's exactly what I need. Thanks. -- Jim Garrison j...@acm.org -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty overstrokes some fonts unexpectedly
Am 26.04.2021 um 01:14 schrieb Lemures Lemniscati via Cygwin: On Sun, 25 Apr 2021 22:33:57 +0200, Thomas Wolff Am 25.04.2021 um 15:41 schrieb Lemures Lemniscati via Cygwin: Hi! mintty overstrokes some fonts unexpectedly. https://gitlab.com/test.cases/mintty-test/-/tree/54ae800e695ecd1741851cab57320a9d0e95a6fd I got a result mintty-sample-msgothic.png. https://gitlab.com/test.cases/mintty-test/-/blob/54ae800e695ecd1741851cab57320a9d0e95a6fd/mintty-sample-msgothic.png In the 4th line of the output, fonts (of u+25cb) were overstruck unexpectedly. And there are other characters also, which are similarly overstruck. This is a Windows bug. Mintty clearly instruct Windows to apply equidistant spacing to achieve fixed-width character cell behaviour. But for certain character ranges, Windows ignores that. Another example for such misbehaviour is the Tibetan block (U+0F00-U+0FFF). Mintty could work around that by rendering characters separately, at a significant penalty for output speed however. Or it could do that only for affected ranges, but criteria to identify them are obscure. Thank you, Thomas. I tried some earlier versions of mintty: * mintty-3.1.0-1 has the same issue * mintty-2.9.6-0 works expectedly in this case. My previous comment was wrong, sorry. The cause of the issue is that the Windows CJK fonts are designed for CJK ambiguous-wide layout. If you run mintty with option Charwidth=ambig-wide, or better in an ambiguous-wide locale like LC_CTYPE=C.utf8@cjkwide, width handling and font rendering will match. Mintty applies auto-narrowing to some characters that would render far out of their character cell, squeezing them into the cell, in order to optimise the trade-off between readability and authentic rendering. Some character ranges were taken out of that mechanism in 2.9.7, including the Geometric Shapes which you've encountered, in this case because they are "geometric" and the assumption was that they should not be tampered for rendering. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
Jim Garrison via Cygwin wrote: Mintty's window does not seem to have any border at the left and bottom. The top of the window has the title menu bar and the right side is the scroll bar. When I have multiple mintty windows open, and they overlap, since there is no border, one window blends into another. I searched mintty's options and there doesn't seem to be a way to specify a border. If the window background is a light color, there's a subtle drop shadow that helps a bit, but with a dark style it's impossible to distinguish the windows. Here's a sample: https://drive.google.com/file/d/10zKWdie_nA-_hzsN8i_GeCw7VadJBmol/view?usp=sharing Is there a way to make it draw a border? As Thomas pointed out, not mintty's fault. I ran into the same issue on first upgrade to Windows 10. Windows 7 allowed one to set window borders; Windows 8 and up don't. But one can adjust registry entries to fix the issue. Check here: https://www.thewindowsclub.com/change-desktop-windows-metrics-border-width-windows-8 The fix outlined there works for Windows 10 too. HTH, ..mark -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty overstrokes some fonts unexpectedly
On Sun, 25 Apr 2021 22:33:57 +0200, Thomas Wolff > > Am 25.04.2021 um 15:41 schrieb Lemures Lemniscati via Cygwin: > > Hi! > > > > mintty overstrokes some fonts unexpectedly. > > https://gitlab.com/test.cases/mintty-test/-/tree/54ae800e695ecd1741851cab57320a9d0e95a6fd > > > > I got a result mintty-sample-msgothic.png. > > https://gitlab.com/test.cases/mintty-test/-/blob/54ae800e695ecd1741851cab57320a9d0e95a6fd/mintty-sample-msgothic.png > > > > In the 4th line of the output, fonts (of u+25cb) were overstruck > > unexpectedly. > > And there are other characters also, which are similarly overstruck. > This is a Windows bug. Mintty clearly instruct Windows to apply equidistant > spacing to achieve fixed-width character cell behaviour. But for certain > character ranges, Windows ignores that. Another example for such misbehaviour > is the Tibetan block (U+0F00-U+0FFF). Mintty could work around that by > rendering characters separately, at a significant penalty for output speed > however. Or it could do that only for affected ranges, but criteria to > identify them are obscure. Thank you, Thomas. I tried some earlier versions of mintty: * mintty-3.1.0-1 has the same issue * mintty-2.9.6-0 works expectedly in this case. Regards, Lem -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty window border?
Am 25.04.2021 um 23:49 schrieb Jim Garrison via Cygwin: Mintty's window does not seem to have any border at the left and bottom. The top of the window has the title menu bar and the right side is the scroll bar. When I have multiple mintty windows open, and they overlap, since there is no border, one window blends into another. I searched mintty's options and there doesn't seem to be a way to specify a border. If the window background is a light color, there's a subtle drop shadow that helps a bit, but with a dark style it's impossible to distinguish the windows. Borders are drawn by Windows, according to Windows style settings. This is not specific to mintty, you'll see the same effect with other applications. Here's a sample: https://drive.google.com/file/d/10zKWdie_nA-_hzsN8i_GeCw7VadJBmol/view?usp=sharing Is there a way to make it draw a border? Applications can draw their own decorations, at considerable implementation effort. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty overstrokes some fonts unexpectedly
Am 25.04.2021 um 15:41 schrieb Lemures Lemniscati via Cygwin: Hi! mintty overstrokes some fonts unexpectedly. https://gitlab.com/test.cases/mintty-test/-/tree/54ae800e695ecd1741851cab57320a9d0e95a6fd How to reproduce Setting mintty to use msgothic.ttc in 20pt, run a following command. perl -e ' binmode STDOUT, ":utf8"; print
Re: Mintty text glitches when using up key
On 28/08/2020 17:45, Thomas Wolff wrote: > Am 28.08.2020 um 17:48 schrieb Hamish McIntyre-Bhatty via Cygwin: >> On 28/08/2020 16:13, Thomas Wolff wrote: >>> Am 28.08.2020 um 16:31 schrieb Hamish McIntyre-Bhatty via Cygwin: My apologies. I mean when a the command with its arguments are long enough to wrap around the width of the Mintty window. >>> That works fine normally but fails under certain additional >>> conditions. Please provide a reproducible test case in order to get >>> suitable comments. Also, which shell do you use? >>> Thomas >> Okay, I'll see if I can come up with a test case. >> >> If I can, would it be better for me to file a bug on GitHub for this >> as well? > Likely not as I firmly believe it's not a terminal issue. I suspect you are correct. After trying to cause the problem in a few different ways, I have not been able to do so. I guess it's either not a bug at all, or it occurs so rarely/in such a small corner case that it's very hard to pin down. Apologies for the noise, and thank you all for your hard work on Cygwin. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: mintty will not accept the letter "e"
Found the problem! One of the FAQs instructed me to add the command set completion-ignore-case on to the .inputrc file. Seeing a "set" command I thought this file was similar to .bashrc so I added the command echo .inputrc to the file (so I could be sure it was being read). After reading the bash manual while awake at 2 this morning I found that the Readline syntax is quite different. I think this command was being mis-parsed as a key binding. Removing the offending line fixed the problem. Thanks to all who responded with suggestions. - Ken -Original Message- From: Cygwin On Behalf Of Thomas Wolff Sent: Saturday, August 29, 2020 5:04 PM To: cygwin@cygwin.com Subject: Re: mintty will not accept the letter "e" Am 30.08.2020 um 00:42 schrieb Ken Reek via Cygwin: > Hi, all. > > All of the sudden, mintty won't accept a lower case "e" -- it just > dings when I try to type one. Upper case "E" is fine, as are all the > other letters. I'm no mintty expert, but I think the e key might have > been remapped somehow. > > Any ideas on how I can fix this? I've killed mintty and started it > again, and also rebooted my machine, to no avail. I'm on Windows 10. > Thanks for any help! What a strange report - there is no way mintty could be causing such an effect. Maybe you've somehow changed your keyboard mapping? What about other letters? Other applications? Windows cmd console? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty will not accept the letter "e"
On 30.8.2020 0:42, Ken Reek via Cygwin wrote: Hi, all. All of the sudden, mintty won't accept a lower case "e" -- it just dings when I try to type one. Upper case "E" is fine, as are all the other letters. I'm no mintty expert, but I think the e key might have been remapped somehow. Any ideas on how I can fix this? I've killed mintty and started it again, and also rebooted my machine, to no avail. I'm on Windows 10. Thanks for any help! - Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple . Hi. Just curious: Please do - in Notepad.exe write text: echo 'Hello' - copy-paste it into mintty (in mintty You probably see: cho 'Hllo') - press Enter What You see next? Vlado -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty will not accept the letter "e"
Am 30.08.2020 um 04:14 schrieb Ken Reek via Cygwin: Have done both of those — no change. On Aug 29, 2020, at 7:15 PM, Yasuhiro KIMURA wrote: From: Ken Reek via Cygwin Subject: Re: mintty will not accept the letter "e" Date: Sat, 29 Aug 2020 19:09:03 -0600 Other apps are fine (like notepad) and I have swapped keyboards with no improvement. Bizarre! I forgot to mention that it won’t take an “e” even in a paste operation. Let me confirm just in case. Does it still happen even if you close and restart mintty? What happens if you restart Windows? Maybe some virus captured your mintty.exe? What's `ls -l /bin/mintty; sum /bin/mintty`? What if you reinstall it? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty will not accept the letter "e"
Have done both of those — no change. > On Aug 29, 2020, at 7:15 PM, Yasuhiro KIMURA wrote: > > From: Ken Reek via Cygwin > Subject: Re: mintty will not accept the letter "e" > Date: Sat, 29 Aug 2020 19:09:03 -0600 > >> Other apps are fine (like notepad) and I have swapped keyboards with no >> improvement. Bizarre! I forgot to mention that it won’t take an “e” even in >> a paste operation. > > Let me confirm just in case. Does it still happen even if you close > and restart mintty? What happens if you restart Windows? > > --- > Yasuhiro KIMURA > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty will not accept the letter "e"
From: Ken Reek via Cygwin Subject: Re: mintty will not accept the letter "e" Date: Sat, 29 Aug 2020 19:09:03 -0600 > Other apps are fine (like notepad) and I have swapped keyboards with no > improvement. Bizarre! I forgot to mention that it won’t take an “e” even in a > paste operation. Let me confirm just in case. Does it still happen even if you close and restart mintty? What happens if you restart Windows? --- Yasuhiro KIMURA -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty will not accept the letter "e"
Other apps are fine (like notepad) and I have swapped keyboards with no improvement. Bizarre! I forgot to mention that it won’t take an “e” even in a paste operation. - Ken > On Aug 29, 2020, at 5:05 PM, Thomas Wolff wrote: > > Am 30.08.2020 um 00:42 schrieb Ken Reek via Cygwin: >> Hi, all. >> >> All of the sudden, mintty won't accept a lower case "e" -- it just dings >> when I try to type one. Upper case "E" is fine, as are all the other >> letters. I'm no mintty expert, but I think the e key might have been >> remapped somehow. >> >> Any ideas on how I can fix this? I've killed mintty and started it again, >> and also rebooted my machine, to no avail. I'm on Windows 10. Thanks for any >> help! > What a strange report - there is no way mintty could be causing such an > effect. Maybe you've somehow changed your keyboard mapping? What about other > letters? Other applications? Windows cmd console? > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty will not accept the letter "e"
Am 30.08.2020 um 00:42 schrieb Ken Reek via Cygwin: Hi, all. All of the sudden, mintty won't accept a lower case "e" -- it just dings when I try to type one. Upper case "E" is fine, as are all the other letters. I'm no mintty expert, but I think the e key might have been remapped somehow. Any ideas on how I can fix this? I've killed mintty and started it again, and also rebooted my machine, to no avail. I'm on Windows 10. Thanks for any help! What a strange report - there is no way mintty could be causing such an effect. Maybe you've somehow changed your keyboard mapping? What about other letters? Other applications? Windows cmd console? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty text glitches when using up key
Am 28.08.2020 um 17:48 schrieb Hamish McIntyre-Bhatty via Cygwin: On 28/08/2020 16:13, Thomas Wolff wrote: Am 28.08.2020 um 16:31 schrieb Hamish McIntyre-Bhatty via Cygwin: My apologies. I mean when a the command with its arguments are long enough to wrap around the width of the Mintty window. That works fine normally but fails under certain additional conditions. Please provide a reproducible test case in order to get suitable comments. Also, which shell do you use? Thomas Okay, I'll see if I can come up with a test case. If I can, would it be better for me to file a bug on GitHub for this as well? Likely not as I firmly believe it's not a terminal issue. Hamish -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty text glitches when using up key
On 28/08/2020 16:13, Thomas Wolff wrote: > Am 28.08.2020 um 16:31 schrieb Hamish McIntyre-Bhatty via Cygwin: >> My apologies. I mean when a the command with its arguments are long >> enough to wrap around the width of the Mintty window. > That works fine normally but fails under certain additional > conditions. Please provide a reproducible test case in order to get > suitable comments. Also, which shell do you use? > Thomas Okay, I'll see if I can come up with a test case. If I can, would it be better for me to file a bug on GitHub for this as well? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty text glitches when using up key
Am 28.08.2020 um 16:31 schrieb Hamish McIntyre-Bhatty via Cygwin: On 28/08/2020 09:33, Thomas Wolff wrote: Am 27.08.2020 um 21:55 schrieb Brian Inglis: On 2020-08-27 10:55, Hamish McIntyre-Bhatty via Cygwin wrote: For a while I've noticed that if I run a long command (usually has to wrap to next line down), that my Mintty session often becomes all messed up if I use the up arrow keys to try and run it again later. Has anyone else experienced this? This description is quite fuzzy. It could be that you resized the window while a program was running, or that some background process sends output to the screen asynchronously. In such cases, the shell loses track of the cursor position and line editing fails. That's not a terminal issue. My apologies. I mean when a the command with its arguments are long enough to wrap around the width of the Mintty window. That works fine normally but fails under certain additional conditions. Please provide a reproducible test case in order to get suitable comments. Also, which shell do you use? Thomas Another, probably unrelated, observation is that if a command produces a lot of long lines that get wrapped, if I make the Mintty window wider, the lines stay wrapped. This behaves much like other terminal emulators I used in the past, including gnome-terminal. At some point, this was fixed in gnome-terminal, so I wonder if that fix would be relevant here too. This was requested to mintty already (https://github.com/mintty/mintty/issues/82) but it's not a traditional terminal feature, so if some terminals have added it as an enhancement, that's not a "fix". Thomas Good to know. Unfortunately I know precious little about how terminal emulation works so I'm not likely to be able to provide a fix, but I'm interested to see if anyone else has experienced this or has found workarounds. It seems to happen with both 32-bit and 64-bit Cygwin for me. Not a problem with long lines - often find myself editing a few lines down in a few hundred characters long after some iterations - I type without thought: $ history | tail > ~/bin/script $ vim + !$ Problem is when you type ahead too fast, hit modifier keys and/or special functions by mistake in the wrong place, and/or when something else is running in the background, or the system is loaded, and mintty does not grab the whole escape sequence to process; often just running reset will restore sanity. [For real fun with mintty, type: $ echo `/usr/bin/env /usr/bin/python` You can kill python from another terminal window or TaskMgr.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty text glitches when using up key
On 28/08/2020 09:33, Thomas Wolff wrote: > Am 27.08.2020 um 21:55 schrieb Brian Inglis: >> On 2020-08-27 10:55, Hamish McIntyre-Bhatty via Cygwin wrote: >>> For a while I've noticed that if I run a long command (usually has to >>> wrap to next line down), that my Mintty session often becomes all >>> messed >>> up if I use the up arrow keys to try and run it again later. Has anyone >>> else experienced this? > This description is quite fuzzy. It could be that you resized the > window while a program was running, or that some background process > sends output to the screen asynchronously. In such cases, the shell > loses track of the cursor position and line editing fails. That's not > a terminal issue. > My apologies. I mean when a the command with its arguments are long enough to wrap around the width of the Mintty window. >>> Another, probably unrelated, observation is that if a command >>> produces a >>> lot of long lines that get wrapped, if I make the Mintty window wider, >>> the lines stay wrapped. This behaves much like other terminal emulators >>> I used in the past, including gnome-terminal. At some point, this was >>> fixed in gnome-terminal, so I wonder if that fix would be relevant >>> here too. > This was requested to mintty already > (https://github.com/mintty/mintty/issues/82) but it's not a > traditional terminal feature, so if some terminals have added it as an > enhancement, that's not a "fix". > Thomas > Good to know. >>> >>> Unfortunately I know precious little about how terminal emulation works >>> so I'm not likely to be able to provide a fix, but I'm interested to >>> see >>> if anyone else has experienced this or has found workarounds. It seems >>> to happen with both 32-bit and 64-bit Cygwin for me. >> Not a problem with long lines - often find myself editing a few lines >> down in a >> few hundred characters long after some iterations - I type without >> thought: >> >> $ history | tail > ~/bin/script >> $ vim + !$ >> >> Problem is when you type ahead too fast, hit modifier keys and/or >> special >> functions by mistake in the wrong place, and/or when something else >> is running >> in the background, or the system is loaded, and mintty does not grab >> the whole >> escape sequence to process; often just running reset will restore >> sanity. >> >> [For real fun with mintty, type: $ echo `/usr/bin/env /usr/bin/python` >> You can kill python from another terminal window or TaskMgr.] >> > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation: https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty text glitches when using up key
Am 27.08.2020 um 21:55 schrieb Brian Inglis: On 2020-08-27 10:55, Hamish McIntyre-Bhatty via Cygwin wrote: For a while I've noticed that if I run a long command (usually has to wrap to next line down), that my Mintty session often becomes all messed up if I use the up arrow keys to try and run it again later. Has anyone else experienced this? This description is quite fuzzy. It could be that you resized the window while a program was running, or that some background process sends output to the screen asynchronously. In such cases, the shell loses track of the cursor position and line editing fails. That's not a terminal issue. Another, probably unrelated, observation is that if a command produces a lot of long lines that get wrapped, if I make the Mintty window wider, the lines stay wrapped. This behaves much like other terminal emulators I used in the past, including gnome-terminal. At some point, this was fixed in gnome-terminal, so I wonder if that fix would be relevant here too. This was requested to mintty already (https://github.com/mintty/mintty/issues/82) but it's not a traditional terminal feature, so if some terminals have added it as an enhancement, that's not a "fix". Thomas Unfortunately I know precious little about how terminal emulation works so I'm not likely to be able to provide a fix, but I'm interested to see if anyone else has experienced this or has found workarounds. It seems to happen with both 32-bit and 64-bit Cygwin for me. Not a problem with long lines - often find myself editing a few lines down in a few hundred characters long after some iterations - I type without thought: $ history | tail > ~/bin/script $ vim + !$ Problem is when you type ahead too fast, hit modifier keys and/or special functions by mistake in the wrong place, and/or when something else is running in the background, or the system is loaded, and mintty does not grab the whole escape sequence to process; often just running reset will restore sanity. [For real fun with mintty, type: $ echo `/usr/bin/env /usr/bin/python` You can kill python from another terminal window or TaskMgr.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty text glitches when using up key
On 2020-08-27 10:55, Hamish McIntyre-Bhatty via Cygwin wrote: > For a while I've noticed that if I run a long command (usually has to > wrap to next line down), that my Mintty session often becomes all messed > up if I use the up arrow keys to try and run it again later. Has anyone > else experienced this? > > Another, probably unrelated, observation is that if a command produces a > lot of long lines that get wrapped, if I make the Mintty window wider, > the lines stay wrapped. This behaves much like other terminal emulators > I used in the past, including gnome-terminal. At some point, this was > fixed in gnome-terminal, so I wonder if that fix would be relevant here too. > > Unfortunately I know precious little about how terminal emulation works > so I'm not likely to be able to provide a fix, but I'm interested to see > if anyone else has experienced this or has found workarounds. It seems > to happen with both 32-bit and 64-bit Cygwin for me. Not a problem with long lines - often find myself editing a few lines down in a few hundred characters long after some iterations - I type without thought: $ history | tail > ~/bin/script $ vim + !$ Problem is when you type ahead too fast, hit modifier keys and/or special functions by mistake in the wrong place, and/or when something else is running in the background, or the system is loaded, and mintty does not grab the whole escape sequence to process; often just running reset will restore sanity. [For real fun with mintty, type: $ echo `/usr/bin/env /usr/bin/python` You can kill python from another terminal window or TaskMgr.] -- 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 IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty emacs-nox pseudorandom color dimming
Am 15.06.2020 um 22:47 schrieb Paul Ausbeck via Cygwin: Dear Sirs: After recently updating my cygwin installation, emacs-nox now pseudorandomly dims some characters after the cursor passes through a character's position. I don't think the problem lies with emacs-nox, but rather with mintty. To support that claim you'd need to provide a clear symptom description and a reproducible test case. You could make a screen log (not shot) or a reproducible command sequence to reveal the effect, then describe what you see and what you'd expect to see. I say this as the color dimming happens when one is using local emacs-nox within a mintty or using remote emacs-nox after sshing within a mintty. After I first discovered the dimming problem I noticed a separate problem with the backspace key in ssh sessions. I then noticed that there was yet another more recent mintty update, so I thought that I'd try that. After applying that update, the backspace problem resolved itself. However, the character dimming problem remains. Regards, Paul Ausbeck -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty slow feedback in keyboard auto repeat mode
Am 03.06.2020 um 22:11 schrieb Michal Grodzki via Cygwin: Hi, mintty has slow keyboard feedback in auto repeat mode. This has already been fixed; 3.1.7 coming this week. Version 3.1.4-1 works correctly. The problem arises from version 3.1.5-1 and it exists in 3.1.6-1. Now I use the old 3.1.4-1 version because of it. I can reproduce this issue on demand by reinstalling mentioned versions of mintty in setup GUI. I do not change anything more. It is quite a fresh and minimal installation of Cygwin. My standard keyboard speed settings in Control Panel / Keyboard / Speed tab: repeat delay: the shortest repeat rate: the fastest The best way to reproduce this I think is to simultaneously open notepad and mintty session. Please hold down a key and recognize the speed of printed characters and compare their speed in notepad and mintty session. My configuration: laptop HP ProBook 640 G2, Windows 10 Enterprise 64-bit Version: 17763.1217, Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 8 GB RAM; Cygwin installed with “just for me” option in a subfolder placed in my Windows desktop. Should I change something in Mintty settings to achieve fast keyboard feedback in auto repeat mode? Is this case related to software changes? Thanks, Michal Grodzki -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty 3.1.5-1 cannot started on Win7 32 bit
Am 03.06.2020 um 12:50 schrieb Ernesto Vigano' via Cygwin: I've been using cygwin on my Win7 32-bit machine without issues for years. I've just updated the package and mintty has been upgraded from 2.9.6-0 to 3.1.5-1. This new release can't be started anymore one my Win7 32 machine. I've reverted back to 2.9.6-0 which works. The problem has been fixed. Please stay at 3.1.4 or older until the next release; 3.1.7 coming in a few days. 3.1.5-1 works on another Win7 64-bit machine This is interesting information. Please report the build numbers (cmd /c ver) on the two machines. Thanks Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
On 2020-02-02 10:48, Anon User via cygwin wrote: > OK I found it. You're right. The same outcome occurs. So I guess it's not > cygwin specific. Sorry to have wasted your time. I guess my Windows install > is messed up somehow. I wish I could get the feedback I need to figure out > what I did to have caused this. I have tried countless searches online for > the analyze wait chain result. > Wild guess: If you have inaccesssible network drives, many calls give a 30S timeout. try googling "windows show hidden drives" or see what you get with: "net use"
Re: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
OK I found it. You're right. The same outcome occurs. So I guess it's not cygwin specific. Sorry to have wasted your time. I guess my Windows install is messed up somehow. I wish I could get the feedback I need to figure out what I did to have caused this. I have tried countless searches online for the analyze wait chain result. -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
Sure. I'm willing to try it. Where do I get that compiler from? -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
On Sun, 2 Feb 2020 09:14:25 + (UTC) "Anon User via cygwin" wrote: > Not sure how to confirm that. I install the built-in OpenSSH client/server > app. Then I start the OpenSSH server service. Then I ssh to 127.0.0.1 and > login fine. There is no waiting on the service starting up nor on the ssh > client connecting to the daemon and getting a shell (Windows 'DOS' shell > though, not bash). I have not seen this hanging outside cygwin yet. Hmm. Then, could you please compile the previous test case using x86_64-w64-mingw32-gcc (mingw compiler) and run the program in pure command prompt (witout cygwin)? -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
Not sure how to confirm that. I install the built-in OpenSSH client/server app. Then I start the OpenSSH server service. Then I ssh to 127.0.0.1 and login fine. There is no waiting on the service starting up nor on the ssh client connecting to the daemon and getting a shell (Windows 'DOS' shell though, not bash). I have not seen this hanging outside cygwin yet. -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
On Sun, 2 Feb 2020 08:31:51 + (UTC) "Anon User via cygwin" wrote: > Same behavior as mintty, tmux, the previous test case, with TaskManager's > analyze wait chain saying it's waiting on Network I/O. > > $ ./a.exeStarted. > ** 1 min wait here ** > CreatePseudoConsole() end.ClosePseudoConsole() end. >From this result, it seems that this is not a cygwin problem. But your system has a problem regarding CreatePseudoConsole() call. I guess Microsoft's OpenSSH server also behaves the same. -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
Same behavior as mintty, tmux, the previous test case, with TaskManager's analyze wait chain saying it's waiting on Network I/O. $ ./a.exeStarted. ** 1 min wait here ** CreatePseudoConsole() end.ClosePseudoConsole() end. -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
On Sat, 1 Feb 2020 23:25:08 + (UTC)
"Anon User via cygwin" wrote:
> $ md5sum /bin/cygwin-console-helper.exe
> 221bdfff7c8ccd1227bacb025bba665b */bin/cygwin-console-helper.exe
This is the right md5sum value.
Then, how about the attached test case?
--
Takashi Yano
#define _WIN32_WINNT 0x0a00
#include
#include
typedef void *HPCON;
#ifndef PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE
#define PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE 0x00020016L
#endif
#ifndef ENABLE_VIRTUAL_TERMINAL_PROCESSING
#define ENABLE_VIRTUAL_TERMINAL_PROCESSING 0x0004
#endif
DWORD WINAPI PipeWriter(LPVOID pipe);
DWORD WINAPI PipeReader(LPVOID pipe);
int main()
{
HMODULE h;
FARPROC f;
COORD size;
HPCON hpCon;
HANDLE inR, inW, outR, outW;
HRESULT (WINAPI *CreatePseudoConsole)(COORD, HANDLE, HANDLE, DWORD, HPCON*);
VOID (WINAPI *ClosePseudoConsole)(HPCON);
h = GetModuleHandle("kernel32.dll");
if (h == INVALID_HANDLE_VALUE) {
fprintf(stderr, "GetModuleHandle() failed.\n");
return 1;
}
f = GetProcAddress(h, "CreatePseudoConsole");
if (f == NULL) {
fprintf(stderr, "GetProcAddress() failed.\n");
return 1;
}
CreatePseudoConsole = (HRESULT (WINAPI *)(COORD, HANDLE, HANDLE, DWORD, HPCON*))f;
f = GetProcAddress(h, "ClosePseudoConsole");
if (f == NULL) {
fprintf(stderr, "GetProcAddress() failed.\n");
return 1;
}
ClosePseudoConsole = (VOID (WINAPI *)(HPCON))f;
CloseHandle(h);
if (!CreatePipe(, , NULL, 0)) {
fprintf(stderr, "CreatePipe() failed.\n");
return 1;
}
if (!CreatePipe(, , NULL, 0)) {
fprintf(stderr, "CreatePipe() failed.\n");
return 1;
}
size.X = 80;
size.Y = 24;
printf("Started.\n");
if (S_OK != CreatePseudoConsole(size, inR, outW, 0, )) {
fprintf(stderr, "CreatePseudoConsole() failed.\n");
return 1;
}
printf("CreatePseudoConsole() end.\n");
CloseHandle(inR);
CloseHandle(outW);
ClosePseudoConsole(hpCon);
CloseHandle(inW);
CloseHandle(outR);
printf("ClosePseudoConsole() end.\n");
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
Re: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
$ md5sum /bin/cygwin-console-helper.exe 221bdfff7c8ccd1227bacb025bba665b */bin/cygwin-console-helper.exe -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
On Sat, 1 Feb 2020 17:40:52 + (UTC) "Anon User via cygwin" wrote: > $ ./a.exe > Start. > ** hangs here about 1 minute ** > PTY opened. > PTY closed. Thanks for testing. Could you please let us know the result of md5sum /bin/cygwin-console-helper.exe -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
What happens is it hangs on that openpty() call. It displays Start immediately. But then around a minute later it shows the rest. $ ./a.exe Start. ** hangs here about 1 minute ** PTY opened. PTY closed. I took the liberty of adding time() calls just before and after the openpty() call: $ ./a.exe Start. 1580578712 PTY opened. 1580578772 PTY closed. It turns out to be exactly 1 minute -- like there's a 60 second timeout waiting for something... -- 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: Mintty/tmux hangs for 1 minute on startup - seems to be a forking issue
On Sat, 1 Feb 2020 07:39:08 + (UTC)
"Anon User via cygwin" wrote:
> I first reported this problem to the Mintty project at GitHub. With their
> help, I was able to debug the issue to the call to forkpty. I installed tmux
> and found it also hangs the exact same way. My guess is any process which
> makes this fork call will hang in a similar way. Rather than copy/paste the
> thread, I'd rather just refer you to there :
> https://github.com/mintty/mintty/issues/960
>
> I will also direct link to the strace log I made which includes my comment
> showing where the hang happens:
> https://github.com/mintty/mintty/files/4136651/mintty.strace.log (Line 718 is
> the hanging point.)
>
> Also Windows 10's analyze wait chain function in TaskManager shows the
> process waiting for Network I/O, but we see no evidence of network activity.
> https://i.imgur.com/Uiw9laH.png
>
> I haven't seen any other windows applications hang thusly, so I'm at a loss
> for what I've done to my windows system to have caused this. Otherwise, I'd
> expect others to share my pain. Any ideas?
What happens if you run the following test code?
#include
#include
#include
int main()
{
int pm, ps;
printf("Start.\n");
openpty(, , NULL, NULL, NULL);
printf("PTY opened.\n");
close(pm);
close(ps);
printf("PTY closed.\n");
return 0;
}
--
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
