Re: default high priority for mintty
On Thu, Feb 29, 2024 at 1:38 PM Charles Russell via Cygwin wrote: > > What is the easiest way to open mintty with high priority by default? > Adding /High to the shortcut command string no longer seems to work in > Windows 11. Assuming that you're using the mintty window to run bash, or another shell, you can include a command in your init script (e.g. .bash_rc) to change the priority using 'renice': renice -n --pid $PPID negative values of 'priorityChange' increase priority up to a maximum of -20 which Windows 10 reports as "realtime" -- 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
default high priority for mintty
What is the easiest way to open mintty with high priority by default? Adding /High to the shortcut command string no longer seems to work in Windows 11. -- 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
Updated: mintty 3.7.1
I have uploaded mintty 3.7.1 with the following changes: Terminal features * Dropped DSR 53 (legacy xterm mistake, dropped in xterm 389). * HTML screen dump supports subscript or superscript. * HTML screen dump supports DEC double-width lines and pairs of double-height lines. * Tweak DECRQCRA Rectangular Checksum to match xterm (~#1225, xterm 390). * Fix status area refresh, especially after restoring a minimized window. * Workaround for rendering failure of top-left background text on background image. * Fix invisible and blinking attributes on background image. * Added XTQMODKEYS to DECRQSS (#1189, xterm 389). Misc * Fix handling of options to be saved (#1246, #1247). * Tune and fix click-opening URL (mintty/wsltty#346, #1254). * Fix layout of Options dialog Selection pane (#1257). Window handling * Fix instable window switching after minimize/restore (#1242, #1249). * Fix window switching (Ctrl+ALT) after minimize/restore (#1242). * New rewrap per-line disable mode DECRST 7723 (deprecated 2027, #1255). * Semi-workaround for transparency loss when resizing unfocused grid-snapped window (#1256). Configuration * New user-definable key Alt for option KeyFunctions (#1245). * New user-definable function intr (~#1245). The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** The easiest way to unsubscribe is to visit <https://cygwin.com/mailman/options/cygwin-announce>, and click 'Unsubscribe'. If you need more information on unsubscribing, start reading here: <https://sourceware.org/lists.html#unsubscribe>.
Re: Desktop partially inert with mintty running
Thank you so much for the link to the github.com/mintty report -- the best problem is a known problem :) I've posted a comment to that report with a little more info. -- 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: Desktop partially inert with mintty running
Am 15.02.2024 um 09:23 schrieb Bruce Jerrick via Cygwin: Has anyone had this happen: Sometimes when I have a mintty running, the upper-left quandrant of the desktop becomes inert to the mouse -- icons do not respond to hovers or clicks, and the desktop background does not respond to a right-click. The remainder of the desktop behaves normally. Everything becomes responsive again when the mintty is closed, but it takes several seconds. This happens under Windoze 10 and 11, and it has happened with cygwin 3.4.9, 3.5.0, and various 3.6.0 (test). It also happened with previous versions of mintty (and current version 3.7.0-1). This is *very* intermittent; I can't reproduce it at will. There is this report: https://github.com/mintty/mintty/issues/1243 but I wasn't able to reproduce 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
Desktop partially inert with mintty running
Has anyone had this happen: Sometimes when I have a mintty running, the upper-left quandrant of the desktop becomes inert to the mouse -- icons do not respond to hovers or clicks, and the desktop background does not respond to a right-click. The remainder of the desktop behaves normally. Everything becomes responsive again when the mintty is closed, but it takes several seconds. This happens under Windoze 10 and 11, and it has happened with cygwin 3.4.9, 3.5.0, and various 3.6.0 (test). It also happened with previous versions of mintty (and current version 3.7.0-1). This is *very* intermittent; I can't reproduce it at will. -- 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
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
mintty ^H weirdness with ssh to one specific Debian 11 system
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 Cygwin Configuration Diagnostics Current System Time: Tue Jan 16 21:07:23 2024 Windows 11 Professional Ver 10.0 Build 22631 Path: C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Windows\System32\OpenSSH C:\Program Files\dotnet C:\Users\jhg\AppData\Local\Microsoft\WindowsApps Output from C:\cygwin64\bin\id.exe UID: 197609(jhg) GID: 197121(None) 197121(None) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users)15(This Organization) 113(Local account) 4095(CurrentSession) 66048(LOCAL) 262154(NTLM Authentication) 401408(Medium Mandatory Level) SysDir: C:\Windows\system32 WinDir: C:\Windows PWD = '/home/jhg' HOME = '/home/jhg' USER = 'jhg' ProgramFiles(x86) = 'C:\Program Files (x86)' !:: = '::\' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' SHELL = '/bin/bash' NUMBER_OF_PROCESSORS = '12' FPS_BROWSER_USER_PROFILE_STRING = 'Default' PROCESSOR_LEVEL = '6' TERM_PROGRAM_VERSION = '3.7.0' USERDOMAIN_ROAMINGPROFILE = 'JHG-LAPTOP' HOSTNAME = 'jhg-laptop' PROGRAMFILES = 'C:\Program Files' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' OS = 'Windows_NT' HOMEDRIVE = 'C:' EFC_7192 = '1' USERDOMAIN = 'JHG-LAPTOP' USERPROFILE = 'C:\Users\jhg' OneDriveConsumer = 'C:\Users\jhg\OneDrive' PRINTER = 'Pantum M7100DW Series PCL6 0001' TZ = 'America/Los_Angeles' ALLUSERSPROFILE = 'C:\ProgramData' ORIGINAL_PATH = '/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/Windows/System32/OpenSSH:/c/Program Files/dotnet:/c/Users/jhg/AppData/Local/Microsoft/WindowsApps' CommonProgramW6432 = 'C:\Program Files\Common Files' USERNAME = 'jhg' OneDrive = 'C:\Users\jhg\OneDrive' COMSPEC = 'C:\Windows\system32\cmd.exe' APPDATA = 'C:\Users\jhg\AppData\Roaming' SYSTEMROOT = 'C:\Windows' LOCALAPPDATA = 'C:\Users\jhg\AppData\Local' COMPUTERNAME = 'JHG-LAPTOP' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info' IGCCSVC_DB = 'AQAAANCMnd8BFdERjHoAwE/Cl+sBQ0uTJ62BlkSPB67Y7tTK+QQCAAAQZgEAACDfv7j0C52Xl7eUI/k3XOnivXpGr54yWFPKSglrCL7BEwAOgAIAACAyNg0flOvw4jYj5mggwKa2s3v4JgvoNQn6nhnnR27rZmASShBU5Zw1B5S2ZG2lHm75GY7d9ameBVz99ejkrG660pnpSwY0I9I+bLAc00Xz0FaOBmjr/6t4YbtVQbqut/7CegG+1yakqSKyJQ80BWogLdEu+2NQbDpInOLhp89wvFZA7wHzN9gEfb3ueLY+V/lcNNP+a6whYeynrqfeZE90FxNVJsI4Cco8k6iJmSVf0jSuX72Tr8MNB4NA3inp5CyJKA==' TERM = 'mintty' LOGONSERVER = '\\JHG-LAPTOP' ZES_ENABLE_SYSMAN = '1' PSModulePath = 'C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules' TEMP = '/tmp' SHLVL = '1' PROCESSOR_REVISION = '9a04' DriverData = 'C:\Windows\System32\Drivers\DriverData' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' LC_CTYPE = 'en_US.UTF-8' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 154 Stepping 4, GenuineInte
Updated: mintty 3.7.0
I have uploaded mintty 3.7.0 with the following changes: Misc * Fix memory leak (mintty/wsltty#340) caused by dynamic emoji checking. * Revise and unify handling of dynamic pathnames for terminal control. * Guard network access via dynamic pathnames. Unicode and Emoji data * Unicode 15.1 update. * Adapt getemojis script to reduced format of unicode.org emoji charts (#1240). Terminal features * Tweak mousewheel scrolling: do not mix line and page events (#1234). * Tweak mousewheel scrolling: page scrolling one line less, consistent with keyboard paging (#1234). * Send Alt modifier with mousewheel events (#1234). * New DECSET 7765 to exchange normal and Alt-modified mouse wheel scrolling (#1234). * Tweak double-click filename/URL selection with colon (#1236). * Filter paste characters causing interrupt signals, according to the current stty settings. * Fixed background in HTML screen dump. Window handling * Better error handling if click-opening file fails. * Save image file with proper access rights. Font rendering * Support size adjustment of alternative fonts, for use as secondary fonts (mintty/wsltty#341). Configuration * Alternative font specification supports initial + for size increase (mintty/wsltty#341). * New option GuardNetworkPaths. * Added STTY to FilterPasteControls settings (xterm 388), as default. The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. It will be in the format: List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin-announce>, <mailto:cygwin-announce-requ...@cygwin.com?subject=unsubscribe> The easiest unsubscribe method is to visit the web page associated with the mailing list as seen above, and click Unsubscribe. Alteratively, you can send email to the list server using the address given in the mailto: above. If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe Please read *all* of the information on unsubscribing that is available starting at this URL.
[ANNOUNCEMENT] Updated: mintty 3.6.5
I have uploaded mintty 3.6.5 with the following changes: Pathname handling * Fix file link detection (#1208), tweak URL detection (#1209). * Restore opening of Windows path names (#1219; broken since 2.8.1). Terminal features * Fix setup of initial status line if monitor DPI is 96. * ESC/Enter restore alphanumeric keyboard input mode while IME is active (#1223). * OSC 50 query response is "?" after font setting failed. * Fix DECRQCRA Rectangular Checksum attribute handling. * Added DECSACE to DECRQSS (xterm 383). * Indicate keyboard layout code in status line. * Fix image display (iTerm2 protocol) in "Sixel display mode". * New DECSET 7780 "Image display mode" to keep cursor position on image output (#1228). * New parameter doNotMoveCursor for iTerm2-style image output (#1228). Window handling * Revamp window operations, esp max/fullscreen, to not raise to foreground. * Group taskbar icons by setting -o Class (#1207). * Handling transparency in tab sets (#1152, #1069, ~#1128). * Workaround against dropping fullscreen on DPI change (#1226). * Preserve "normal position" (unzoomed) during screen changes (~#1226). Configuration * New user-definable function compose (#1211). * New option setting ComposeKey=capslock (#1211). * New option ConfirmReset to guard confirm dialog on interactive reset (#1173). * Support changed Drag-and-drop format for some theme file downloads. * New option KeyAlphaMode (#1223). * New option -Rw to report the Windows window id. * New option StatusDebug to include debug information in the status line. The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- 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
Updated: mintty 3.6.5
I have uploaded mintty 3.6.5 with the following changes: Pathname handling * Fix file link detection (#1208), tweak URL detection (#1209). * Restore opening of Windows path names (#1219; broken since 2.8.1). Terminal features * Fix setup of initial status line if monitor DPI is 96. * ESC/Enter restore alphanumeric keyboard input mode while IME is active (#1223). * OSC 50 query response is "?" after font setting failed. * Fix DECRQCRA Rectangular Checksum attribute handling. * Added DECSACE to DECRQSS (xterm 383). * Indicate keyboard layout code in status line. * Fix image display (iTerm2 protocol) in "Sixel display mode". * New DECSET 7780 "Image display mode" to keep cursor position on image output (#1228). * New parameter doNotMoveCursor for iTerm2-style image output (#1228). Window handling * Revamp window operations, esp max/fullscreen, to not raise to foreground. * Group taskbar icons by setting -o Class (#1207). * Handling transparency in tab sets (#1152, #1069, ~#1128). * Workaround against dropping fullscreen on DPI change (#1226). * Preserve "normal position" (unzoomed) during screen changes (~#1226). Configuration * New user-definable function compose (#1211). * New option setting ComposeKey=capslock (#1211). * New option ConfirmReset to guard confirm dialog on interactive reset (#1173). * Support changed Drag-and-drop format for some theme file downloads. * New option KeyAlphaMode (#1223). * New option -Rw to report the Windows window id. * New option StatusDebug to include debug information in the status line. The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas
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
mintty 3.6.4 status line problem
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. -- Ross Boulet Boulet and Associates 713.202.3567 - cygcheck.out Description: cygcheck.out -- 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
mintty mouse behavior with vim
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. -- 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 > wr
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
Mintty terminal crashes after changing the default home via nsswitch.conf and launch in a new profile in Windows 11
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 cygcheck_after_crash.out Description: Binary data cygcheck_before_crash.out 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
[ANNOUNCEMENT] Updated: mintty 3.6.4
I have uploaded mintty 3.6.4 with the following changes: Highlight * Dynamic support for flags emojis, deployment script. Terminal features * Tweak response code to XTQALLOWED OSC 60 and XTQDISALLOWED OSC 61 (xterm 378). * Readline mouse modes (DECSET 2001 / 2002 / 2003, xterm 379). * Hover and open URL: support parentheses (#1196). * Fix cursor artefacts in connection with ClicksPlaceCursor=yes. * Fix mouse-paste while still selecting. * Support multi-line progress detection. Windows integration * Manage user-set HOME for calling Windows from WSL (mintty/wsltty#324, ~mintty/wsltty#76). * Support OSC 7 directory cloning if cloning WSL window while in rootfs. Configuration * Status line is configurable in Options menu, switchable from context menu. * New user-definable function toggle-tabbar (#1201). * Setting ClicksPlaceCursor presets all readline mouse modes. * Dynamic support for flags emojis, deployment script (~mintty/wsltty#321). * `MINTTY_DEBUG=C mintty ...` will list loaded config files (#1181). * New option ProgressScan. The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- 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
Updated: mintty 3.6.4
I have uploaded mintty 3.6.4 with the following changes: Highlight * Dynamic support for flags emojis, deployment script. Terminal features * Tweak response code to XTQALLOWED OSC 60 and XTQDISALLOWED OSC 61 (xterm 378). * Readline mouse modes (DECSET 2001 / 2002 / 2003, xterm 379). * Hover and open URL: support parentheses (#1196). * Fix cursor artefacts in connection with ClicksPlaceCursor=yes. * Fix mouse-paste while still selecting. * Support multi-line progress detection. Windows integration * Manage user-set HOME for calling Windows from WSL (mintty/wsltty#324, ~mintty/wsltty#76). * Support OSC 7 directory cloning if cloning WSL window while in rootfs. Configuration * Status line is configurable in Options menu, switchable from context menu. * New user-definable function toggle-tabbar (#1201). * Setting ClicksPlaceCursor presets all readline mouse modes. * Dynamic support for flags emojis, deployment script (~mintty/wsltty#321). * `MINTTY_DEBUG=C mintty ...` will list loaded config files (#1181). * New option ProgressScan. The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas
Re: Maximizing windows during "git log" locks mintty both in "Git for Windows" and cygwin 3.4.3
On Tue, 10 Jan 2023 22:24:39 +0100 Francesco Pretto wrote: > On Tue, 10 Jan 2023 at 18:03, Takashi Yano wrote: > > What does "uname -a" in Git for Windows say? > > > > MINGW64_NT-10.0-19045 LAPTOPBBK2 3.3.6-341.x86_64 2022-09-05 20:28 UTC > x86_64 Msys Thanks. Actually, I already fixed that issue on 22 Dec. 2022. https://cygwin.com/pipermail/cygwin-patches/2022q4/012107.html Even you start git in Git for Windows from cygwin, msys-2.0.dll in Git for Windows is used for less called from git. Therefore, applying this patch for msys-2.0.dll will fixes the isseu. -- 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: Maximizing windows during "git log" locks mintty both in "Git for Windows" and cygwin 3.4.3
On Tue, 10 Jan 2023 at 18:03, Takashi Yano wrote: > What does "uname -a" in Git for Windows say? > MINGW64_NT-10.0-19045 LAPTOPBBK2 3.3.6-341.x86_64 2022-09-05 20:28 UTC x86_64 Msys -- 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: Maximizing windows during "git log" locks mintty both in "Git for Windows" and cygwin 3.4.3
On Tue, Jan 10, 2023 at 04:50:26PM +0100, Francesco Pretto via Cygwin wrote: > Hello, > > I want to report a bug in mintty that is mostly suffered by "Git for > Windows" users, which in version 2.39.0.2 they are using mintty 3.6.1. > The bug has been reported in this "Git for Windows" issue[1]. > Basically maximizing the mintty window during a "git log" session > locks the tty session and the window must be quit/killed. I can > reproduce within a vanilla cygwin mintty 3.6.3 session, which is > present in the latest cygwin 3.4.3, using the same "Git for Windows" > git binary. To reproduce; > > - Open a cygwin mintty window, keep it **default** size, don't maximize here; > - Go to a git repository directory; > - Enter "git log" (I'm using the git binary from "Git for Windows", > location "/cygdrive/c/Program Files/Git/cmd/git"; > - Maximize the window; > - Try to exit "git log" by pressing "q" -> lock! I've tried this, as described, using both Cygwin's git and MinTTY, and using the Git for Windows versions, and both work just fine for me. However... > There was some debate of who was supposed to report the issue to this > ML. Please, ask for more details "Git for Windows" maintainers, if you > need, either by contacting them here/privately or writing to their > Github issue. > > Regards, > Francesco Pretto > > [1] https://github.com/git-for-windows/git/issues/4060 ...this is the same issue on GitHub as was reported at [0], however in that email thread the problem occurred only when using the Windows terminal emulators, calling git or less from within a PowerShell or cmd window, *not* when using MinTTY. I believe that's fixed in an upcoming Cygwin release, per [1], although I don't know when that release will happen, or how long it will take downstream projects like Git for Windows to pick it up. [0]: https://cygwin.com/pipermail/cygwin/2022-December/252737.html [1]: https://cygwin.com/pipermail/cygwin/2022-December/252745.html I'll put a comment on the Git for Windows issue now, more-or-less duplicating the above. Adam -- 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: Maximizing windows during "git log" locks mintty both in "Git for Windows" and cygwin 3.4.3
On Tue, 10 Jan 2023 16:50:26 +0100 Francesco Pretto wrote: > I want to report a bug in mintty that is mostly suffered by "Git for > Windows" users, which in version 2.39.0.2 they are using mintty 3.6.1. > The bug has been reported in this "Git for Windows" issue[1]. > Basically maximizing the mintty window during a "git log" session > locks the tty session and the window must be quit/killed. I can > reproduce within a vanilla cygwin mintty 3.6.3 session, which is > present in the latest cygwin 3.4.3, using the same "Git for Windows" > git binary. To reproduce; > > - Open a cygwin mintty window, keep it **default** size, don't maximize here; > - Go to a git repository directory; > - Enter "git log" (I'm using the git binary from "Git for Windows", > location "/cygdrive/c/Program Files/Git/cmd/git"; > - Maximize the window; > - Try to exit "git log" by pressing "q" -> lock! What does "uname -a" in Git for Windows say? -- 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
Maximizing windows during "git log" locks mintty both in "Git for Windows" and cygwin 3.4.3
Hello, I want to report a bug in mintty that is mostly suffered by "Git for Windows" users, which in version 2.39.0.2 they are using mintty 3.6.1. The bug has been reported in this "Git for Windows" issue[1]. Basically maximizing the mintty window during a "git log" session locks the tty session and the window must be quit/killed. I can reproduce within a vanilla cygwin mintty 3.6.3 session, which is present in the latest cygwin 3.4.3, using the same "Git for Windows" git binary. To reproduce; - Open a cygwin mintty window, keep it **default** size, don't maximize here; - Go to a git repository directory; - Enter "git log" (I'm using the git binary from "Git for Windows", location "/cygdrive/c/Program Files/Git/cmd/git"; - Maximize the window; - Try to exit "git log" by pressing "q" -> lock! There was some debate of who was supposed to report the issue to this ML. Please, ask for more details "Git for Windows" maintainers, if you need, either by contacting them here/privately or writing to their Github issue. Regards, Francesco Pretto [1] https://github.com/git-for-windows/git/issues/4060 -- 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
[ANNOUNCEMENT] Updated: mintty 3.6.3
I have uploaded mintty 3.6.3 with the following changes: Terminal features * Fixed double-width characters not to wrap if auto-wrap disabled. * TAB may wrap to next line, or cause subsequent wrap, if enabled (#1182). * Fixed auto-wrap behaviour in double-width lines. * Overstriking character writing mode also switched with DECSET 20 (VK100, #1184). * Fixed OSC 7 (set working directory) to handle ~ prefix. * Added XTQMODKEYS state query (xterm 373). * Withdrawn DEC private SGRs (/#1171, conflict with XTQMODKEYS). * Added XTQALLOWED OSC 60 and OSC 61 (xterm 373). Unicode and Emoji data * Extend emoji information by considering Unicode file emoji-test.txt. Configuration * Option WrapTab (#1182). * New user-definable function toggle-opaque (#1168), replaces transparency-opaque. Other * Fixed crash in Options dialog when Printer Service is stopped (#1185). The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- 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
Updated: mintty 3.6.3
I have uploaded mintty 3.6.3 with the following changes: Terminal features * Fixed double-width characters not to wrap if auto-wrap disabled. * TAB may wrap to next line, or cause subsequent wrap, if enabled (#1182). * Fixed auto-wrap behaviour in double-width lines. * Overstriking character writing mode also switched with DECSET 20 (VK100, #1184). * Fixed OSC 7 (set working directory) to handle ~ prefix. * Added XTQMODKEYS state query (xterm 373). * Withdrawn DEC private SGRs (/#1171, conflict with XTQMODKEYS). * Added XTQALLOWED OSC 60 and OSC 61 (xterm 373). Unicode and Emoji data * Extend emoji information by considering Unicode file emoji-test.txt. Configuration * Option WrapTab (#1182). * New user-definable function toggle-opaque (#1168), replaces transparency-opaque. Other * Fixed crash in Options dialog when Printer Service is stopped (#1185). The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas
[ANNOUNCEMENT] Updated: mintty 3.6.2
I have uploaded mintty 3.6.2 with the following changes: Unicode and Emoji data * Unicode 15.0 update. Terminal features * Status line area support (VT320, xterm 371), DECSSDT, DECSASD. * Extended multi-line host-writable status area, DECSSDT 2 N. * Combined sub/superscript attributes render small script (#1171). * Adjusted subscript position (~#1171). * Alternative DEC private SGRs for sub/superscript (#1171). * Revamp line cursor handling, size changeable by CSI ? N c (#1157, #1175). * Support DECSET 117 (DECECM, VT520). * Added DECARR to DECRQSS. * Prevent font zooming for resizing controls like CSI 8. * Optionally visualize margins by dimming. Keyboard handling * Not suppressing user-defined KeyFunctions for keypad keys in keypad modes (#1161). * Alt+keypad-minus initiates decimal numeric input in case an Alt+numpad-digit key is assigned a user-defined function. Mouse handling * Configurable modifiers for hovering and link opening (#1169). * Support super and hyper modifiers with mouse functions. * Fixed mouse pixel coordinates limits (DECSET 1016). Initialisation * Grab focus again after showing the window, reducing focus delay for Windows 11 (#1113). Configuration * Option OldKeyFunctionsKeypad (~#1161, not listed in manual). * Option OpeningMod (#1169). * New user-definable function reset-noask. * Option DimMargins, user-definable function toggle-dim-margins. * Option StatusLine, user-definable function toggle-status-line. * Background image mode '+' for combined scaling and tiling (#1180). * New user-definable function transparency-opaque (#1168). Other * Fixed crash condition on user-defined commands (#1174). * Add confirm dialog to Reset triggered by menu or Alt+F8 (#1173). The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- 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
Updated: mintty 3.6.2
I have uploaded mintty 3.6.2 with the following changes: Unicode and Emoji data * Unicode 15.0 update. Terminal features * Status line area support (VT320, xterm 371), DECSSDT, DECSASD. * Extended multi-line host-writable status area, DECSSDT 2 N. * Combined sub/superscript attributes render small script (#1171). * Adjusted subscript position (~#1171). * Alternative DEC private SGRs for sub/superscript (#1171). * Revamp line cursor handling, size changeable by CSI ? N c (#1157, #1175). * Support DECSET 117 (DECECM, VT520). * Added DECARR to DECRQSS. * Prevent font zooming for resizing controls like CSI 8. * Optionally visualize margins by dimming. Keyboard handling * Not suppressing user-defined KeyFunctions for keypad keys in keypad modes (#1161). * Alt+keypad-minus initiates decimal numeric input in case an Alt+numpad-digit key is assigned a user-defined function. Mouse handling * Configurable modifiers for hovering and link opening (#1169). * Support super and hyper modifiers with mouse functions. * Fixed mouse pixel coordinates limits (DECSET 1016). Initialisation * Grab focus again after showing the window, reducing focus delay for Windows 11 (#1113). Configuration * Option OldKeyFunctionsKeypad (~#1161, not listed in manual). * Option OpeningMod (#1169). * New user-definable function reset-noask. * Option DimMargins, user-definable function toggle-dim-margins. * Option StatusLine, user-definable function toggle-status-line. * Background image mode '+' for combined scaling and tiling (#1180). * New user-definable function transparency-opaque (#1168). Other * Fixed crash condition on user-defined commands (#1174). * Add confirm dialog to Reset triggered by menu or Alt+F8 (#1173). The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas
Re: Updated: mintty 3.6.2
Am 14/11/2022 um 17:24 schrieb Achim Gratz: Thomas Wolff writes: I have uploaded mintty 3.6.2 with the following changes: Shouldn't this mail have been sent to the announce list instead? Oops. And thanks. Regards, Achim.
Re: Updated: mintty 3.6.2
Thomas Wolff writes: > I have uploaded mintty 3.6.2 with the following changes: Shouldn't this mail have been sent to the announce list instead? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Updated: mintty 3.6.2
I have uploaded mintty 3.6.2 with the following changes: Unicode and Emoji data * Unicode 15.0 update. Terminal features * Status line area support (VT320, xterm 371), DECSSDT, DECSASD. * Extended multi-line host-writable status area, DECSSDT 2 N. * Combined sub/superscript attributes render small script (#1171). * Adjusted subscript position (~#1171). * Alternative DEC private SGRs for sub/superscript (#1171). * Revamp line cursor handling, size changeable by CSI ? N c (#1157, #1175). * Support DECSET 117 (DECECM, VT520). * Added DECARR to DECRQSS. * Prevent font zooming for resizing controls like CSI 8. * Optionally visualize margins by dimming. Keyboard handling * Not suppressing user-defined KeyFunctions for keypad keys in keypad modes (#1161). * Alt+keypad-minus initiates decimal numeric input in case an Alt+numpad-digit key is assigned a user-defined function. Mouse handling * Configurable modifiers for hovering and link opening (#1169). * Support super and hyper modifiers with mouse functions. * Fixed mouse pixel coordinates limits (DECSET 1016). Initialisation * Grab focus again after showing the window, reducing focus delay for Windows 11 (#1113). Configuration * Option OldKeyFunctionsKeypad (~#1161, not listed in manual). * Option OpeningMod (#1169). * New user-definable function reset-noask. * Option DimMargins, user-definable function toggle-dim-margins. * Option StatusLine, user-definable function toggle-status-line. * Background image mode '+' for combined scaling and tiling (#1180). * New user-definable function transparency-opaque (#1168). Other * Fixed crash condition on user-defined commands (#1174). * Add confirm dialog to Reset triggered by menu or Alt+F8 (#1173). The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas
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
[mintty] Suppress a key completely
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? -- With best regards, Andrey Repin Sunday, July 10, 2022 16:44:16 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 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
mintty crashes on Windows 7
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 ??
Thread 5 (Thread 6896.0x1eb8 "waitproc"):
#0 0x7791980a in ntdll!ZwReadFile () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x07feffb31a6a in ReadFile () from C:\Windows\system32\KernelBase.dll
No symbol table info available.
#2 0x776a0599 in ReadFile () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#3 0x00018010ca04 in proc_waiter (arg=) at
../../../../winsup/cygwin/pinfo.cc:1214
nb = 0
buf = 0 '\000'
vchild = { = {h = 0x228, hProcess = 0x22c, rd_proc_pipe
= 0x220}, destroy = false, winpid_hdl = 0x0, procinfo = 0x3a, waiter_ready
= false, wait_thread = 0x180238898 }
si = {si_signo = 20, si_code = 28, si_pid = 502, si_uid = 0, si_errno =
0, {__pad = {0 }, _si_commune = {_si_code = 0,
_si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0,
{{_si_fd = 0, _si_flags = 0}, _si_pipe_unique_id = 0, _si_str = 0x0}},
{{si_sigval = {sival_int = 0, sival_ptr = 0x0}, si_value = {sival_int = 0,
sival_ptr = 0x0}}, {si_tid = 0, si_overrun = 0}}, {si_status = 0, si_utime = 0,
si_stime = 0}, si_addr = 0x0, {__pad2 = {0 }, si_cyg = 0x0}}}
pid = 502
its_me = false
__PRETTY_FUNCTION__ = "DWORD proc_waiter(void*)"
#4 0x000180046583 in cygthread::callfunc (this=this@entry=0x180238898
, issimplestub=issimplestub@entry=false) at
../../../../winsup/cygwin/cygthread.cc:48
pass_arg =
#5 0x000180046b46 in cygthread::stub (arg=arg@entry=0x180238898
) at ../../../../winsup/cygwin/cygthread.cc:91
notify =
info = 0x180238898
__PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#6 0x000180047716 in _cygtls::call2 (this=0x24ace00, func=0x180046ac0
, arg=0x180238898 ,
buf=buf@entry=0x24acd50) at ../../../../winsup/cygwin/cygtls.cc:40
res =
#7 0x0001800477c4 in _cygtls::call (func=, arg=) at ../../../../winsup/cygwin/cygtls.cc:27
buf = '\000' ,
"?M#\200\001\000\000\000\220N#\200\001\000\000\000HO#\200\001", '\000' , "\377\377\377\377\000\000\000\000\220Y\033\200\001", '\000' ,
"\001\000\000\000\000\000\000\000\016\063\315?4\022m?\336?\005\000\v", '\000'
, "\003\000\000\000\000\000\000\000?M#\200\001", '\000'
, "\200\326?J\002", '\000' , "\002",
'\000' , "?\036", '\000' ,
"\230\210#\200\001", '\000' , "X?J\002", '\000' , "?\027c\307", '\000' , "\nTjw", '\000' ,
"\037\000\004\033\000\000\000\000\020\004\000\000\000\000\000\000\210\371?<\000\000\000\000\000\001\000\000\000\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000??\230w\000\000\000\000\212?<\000\000\000\000\000??<\000\000\000\000\000\200\371?<",
'\000' ,
"\001\000\000\000\000\000\000\000D\000\000\000\000\000\000\000 #", '\000'
,
"\004\000\000\000\003\300\002\005\000\000\000\000\000\000\000\000\200\371?<\000\000\000\000\000\220?<\000\000\000\000\000\177\000\000\000\000\000\000\000\220?<",
'\000' , "D", '\000' , "\177\000\000\000
#", '\000' , "D", '\000' , "\020\004",
'\000' ,
"\220?<\000\000\000\000\000\060\000\000\000\000\000\000\000\060\002;", '\000'
, " 6\002", '\000' ,
"t\002;\000\000\000\000\000\060\002;\000\000\000\000\000\177", '\000' , "\060\002;", '\000' , "d#\004C", '\000' , "\002\000\004\006", '\000' , "(1?w", '\000'
,
";\000\000\000\000\000\000\000;\000\000\000\000\000\020\004", '\000' ,
"\234{\215w\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000\020\0
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
mintty phantom key presses
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. fdsa Description: Binary data cygcheck.out 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: [ANNOUNCEMENT] Updated: mintty 3.6.1
On Sun, 24 Apr 2022 at 15:42, Thomas Wolff wrote: > > I have uploaded mintty 3.6.1 with the following changes: > > Window handling >* Terminal reflow (#82, #219): fixed crash condition on irregular > reflow chunks. >* Terminal reflow (#82, #219): fixed memory leak. > > Terminal features >* Visual input feedback: don't obscure text when just pressing Alt. >* Separate foreground and background values for ANSI colours (#1151). >* OSC 7704 for setting ANSI colours distinct from palette colours > (#1151). > > Keyboard handling >* Support longer multi-char keyboard input (a.k.a. "ligatures" in > Windows) (#1155). > > Configuration (contributed by Andy Koppe) >* ANSI colour specification accepts foreground ; background values > (#1151). >* Tuned themes helmholtz (default) and kohlrausch for legibility (#1156). > > The homepage is at http://mintty.github.io/ > It also links to the issue tracker. Thanks Thomas. In the default 'helmholtz' theme, the separate foreground and background colour settings are used for blue, red, magenta and grey (aka "BoldBlack"), with the background variants darker than the foreground ones. Foreground blue is significantly brighter again than before, to help readability on a black background. It's still not as bright as the other colours, because it's also often used on bright backgrounds, but I think it now looks ok in syntax highlighting schemes that use it. The 'kohlrausch' theme is repurposed as a black-on-white version of 'helmholtz', with the foreground colour variants darker than the background ones. It's probably best used with the "show bold as font" mode. Note that as the theme contains settings for the default foreground and background colours, those can't then be changed in the options dialog. To be able to change them anyway, copy the colour settings from /usr/share/mintty/themes/kohlrausch into ~/.minttyrc and remove the ThemeFile setting. 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
[ANNOUNCEMENT] Updated: mintty 3.6.1
I have uploaded mintty 3.6.1 with the following changes: Window handling * Terminal reflow (#82, #219): fixed crash condition on irregular reflow chunks. * Terminal reflow (#82, #219): fixed memory leak. Terminal features * Visual input feedback: don't obscure text when just pressing Alt. * Separate foreground and background values for ANSI colours (#1151). * OSC 7704 for setting ANSI colours distinct from palette colours (#1151). Keyboard handling * Support longer multi-char keyboard input (a.k.a. "ligatures" in Windows) (#1155). Configuration (contributed by Andy Koppe) * ANSI colour specification accepts foreground ; background values (#1151). * Tuned themes helmholtz (default) and kohlrausch for legibility (#1156). The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- 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
Updated: mintty 3.6.1
I have uploaded mintty 3.6.1 with the following changes: Window handling * Terminal reflow (#82, #219): fixed crash condition on irregular reflow chunks. * Terminal reflow (#82, #219): fixed memory leak. Terminal features * Visual input feedback: don't obscure text when just pressing Alt. * Separate foreground and background values for ANSI colours (#1151). * OSC 7704 for setting ANSI colours distinct from palette colours (#1151). Keyboard handling * Support longer multi-char keyboard input (a.k.a. "ligatures" in Windows) (#1155). Configuration (contributed by Andy Koppe) * ANSI colour specification accepts foreground ; background values (#1151). * Tuned themes helmholtz (default) and kohlrausch for legibility (#1156). The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas
Re: windows netsh/route output translated to English in mintty
Greetings, Ilya Basin! > Hi. One of my PCs still has Windows 7 and I noticed that when I run > netsh interface ipv4 show route > or > route print > In Mintty, the output is translated to English and when I run these > commands from Cygwin started in a Windows console the output is in the same > language as the OS. Does Cygwin do that? No, it is netsh does. It checks the console codepage and outputs in english if it is not an OEM CP. > Secondly, it doesn't seem to be affected by TERM= LC_ALL= , redirections or > even setsid. Right. > And I also noticed that when the "Interface List" section of "route print" > is translated to English the national interface names containing "Microsoft > ISATAP" are omitted completely, including the newlines so the output looks > like this: > ... > 1...Software Loopback Interface 1 > 12...00 00 00 00 00 00 00 e0 14...00 00 00 00 00 00 00 e0 16...00 00 > 00 00 00 00 00 e0 18...00 00 00 00 00 00 00 e0 20...00 00 00 00 00 00 00 > e0 26...00 00 00 00 00 00 00 e0 > === > > IPv4 Route Table > ... > Does anybody know the reason? Microsoft stupidity. -- With best regards, Andrey Repin Tuesday, April 19, 2022 21:13:47 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: windows netsh/route output translated to English in mintty
On 2022-04-07 03:35, Takashi Yano wrote: On Thu, 7 Apr 2022 11:38:28 +0300 Ilya Basin wrote: Hi. One of my PCs still has Windows 7 and I noticed that when I run netsh interface ipv4 show route or route print In Mintty, the output is translated to English and when I run these commands from Cygwin started in a Windows console the output is in the same language as the OS. Does Cygwin do that? Secondly, it doesn't seem to be affected by TERM= LC_ALL= , redirections or even setsid. And I also noticed that when the "Interface List" section of "route print" is translated to English the national interface names containing "Microsoft ISATAP" are omitted completely, including the newlines so the output looks like this: ... 1...Software Loopback Interface 1 12...00 00 00 00 00 00 00 e0 14...00 00 00 00 00 00 00 e0 16...00 00 00 00 00 00 00 e0 18...00 00 00 00 00 00 00 e0 20...00 00 00 00 00 00 00 e0 26...00 00 00 00 00 00 00 e0 === IPv4 Route Table ... Does anybody know the reason? That's because code page is set to CP_UTF8 (65001) by default in pty without pseudo console support for a certain reason. https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html You can change the code page by chcp.com Windows program does not reffer to TERM, LC_ALL, etc. but code page. In mintty, see Options/Text/Locale|Character set or .minttyrc entries: # # Locale ll[l]_CC language_country Locale=en_CA # # Character set UTF-8|... Charset=UTF-8 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [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: windows netsh/route output translated to English in mintty
On Thu, 7 Apr 2022 11:38:28 +0300 Ilya Basin wrote: > Hi. One of my PCs still has Windows 7 and I noticed that when I run > netsh interface ipv4 show route > or > route print > > In Mintty, the output is translated to English and when I run these commands > from Cygwin started in a Windows console the output is in the same language > as the OS. Does Cygwin do that? > > Secondly, it doesn't seem to be affected by TERM= LC_ALL= , redirections or > even setsid. > > And I also noticed that when the "Interface List" section of "route print" is > translated to English the national interface names containing "Microsoft > ISATAP" are omitted completely, including the newlines so the output looks > like this: > > ... > 1...Software Loopback Interface 1 > 12...00 00 00 00 00 00 00 e0 14...00 00 00 00 00 00 00 e0 16...00 00 > 00 00 00 00 00 e0 18...00 00 00 00 00 00 00 e0 20...00 00 00 00 00 00 00 e0 > 26...00 00 00 00 00 00 00 e0 > === > > IPv4 Route Table > ... > > Does anybody know the reason? That's because code page is set to CP_UTF8 (65001) by default in pty without pseudo console support for a certain reason. https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html You can change the code page by chcp.com Windows program does not reffer to TERM, LC_ALL, etc. but code page. -- 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
windows netsh/route output translated to English in mintty
Hi. One of my PCs still has Windows 7 and I noticed that when I run netsh interface ipv4 show route or route print In Mintty, the output is translated to English and when I run these commands from Cygwin started in a Windows console the output is in the same language as the OS. Does Cygwin do that? Secondly, it doesn't seem to be affected by TERM= LC_ALL= , redirections or even setsid. And I also noticed that when the "Interface List" section of "route print" is translated to English the national interface names containing "Microsoft ISATAP" are omitted completely, including the newlines so the output looks like this: ... 1...Software Loopback Interface 1 12...00 00 00 00 00 00 00 e0 14...00 00 00 00 00 00 00 e0 16...00 00 00 00 00 00 00 e0 18...00 00 00 00 00 00 00 e0 20...00 00 00 00 00 00 00 e0 26...00 00 00 00 00 00 00 e0 === IPv4 Route Table ... Does anybody know the reason? -- 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
