Re: cygwin-3.1.0 and mintty from desktop shortcut
On Sun, 7 Jun 2020 00:15:59 -0600 Brian Inglis wrote: > On 2020-06-06 19:35, Takashi Yano via Cygwin wrote: > > On Sat, 06 Jun 2020 13:20:16 +0200 > > ASSI wrote: > >> Takashi Yano via Cygwin writes: > 1. Rename /usr/share/locale to something else, like local.bak. > 2. Start mintty in the usual way. > 3. Rename the directory from step 1 back to /usr/share/local. > 4. Work just like the problem never existed either in the shell running > inside the mintty or even start a new mintty. > >>> > >>> I guess renaming /usr/share/locale/locale.alias is enough. > >> > >> I've had some time to look into this problem again after having updated > >> Cygwin to the latest and greatest. Indeed, when > >> > >> /usr/share/locale/locale.alias > >> > >> gets renamed, the problem also goes away. This is great because I don't > >> really need the locale aliases for anything. Btw, my laptop got > >> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't > >> specific to 1803 as was supected earlier. > >> > >> I then tried to figure out what exactly causes the problem and it turns > >> out that it's the _presence_ of this file with the additional condition > >> that it must not be owned by the user starting the mintty/shell. Since > >> I install Cygwin on my work laptop with a different (admin) account and > >> not my (non-admin) user account, that explains why I am seeing the > >> problem there and not on other machines. Before you are going to > >> suggest that it's the admin vs. non-admin rights: no, if I create a > >> locale.alias with my user account (either as an empty file or a copy of > >> the backup file), then the admin account is unable to start a shell in > >> mintty successfully. I have no idea why the ownership of a file that > >> onnly should get read (and is readable by everyone) would have the > >> effect I'm seeing, but maybe that gives the clue on where to look for a > >> fix. > > > > Thanks for the additional information. I tested the following steps > > to confirm if the problem can be reproduced. > > > > 1. Enable Administrator account. > > 2. Remove all groups from account yano other than Users. > > 3. Install cygwin for all with gettext package as Administrator. > > 4. Run mintty from desktop shortcut as Administrator. > > 5. Run mintty from desktop shortcut as yano. > > > > Both 4 and 5 successfully open mintty window with shell. > > > > I wonder what is the difference between my environment and yours. > > Locale setting? > > fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls > get_langinfo@2768 calls@2781 > nlsfuncs.cc(__set_locale_from_locale_alias)@1462 > which opens /usr/share/locale/locale.alias@1472. > > One problem I see with that is that __set_locale_from_locale_alias is meant to > be called when loadlocale fails with an unrecognized locale, but in > get_langinfo@2778 if the locale is not found, it is defaulted to C before > __set_locale_from_locale_alias is called, defeating the purpose: > > const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale); > if (!locale) > locale = "C"; > > char tmp_locale[ENCODING_LEN + 1]; > char *ret = __set_locale_from_locale_alias (locale, tmp_locale); > if (ret) > locale = tmp_locale; Hmm..., you are right. Furthermore, __set_locale_from_locale_alias() here is completely unnecessary since it is already processed in __loadlocale(). I will remove that code. -- 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-3.1.0 and mintty from desktop shortcut
On Sun, 7 Jun 2020 16:42:52 +0900 Takashi Yano via Cygwin wrote: > On Sun, 7 Jun 2020 00:15:59 -0600 > Brian Inglis wrote: > > On 2020-06-06 19:35, Takashi Yano via Cygwin wrote: > > > On Sat, 06 Jun 2020 13:20:16 +0200 > > > ASSI wrote: > > >> Takashi Yano via Cygwin writes: > > 1. Rename /usr/share/locale to something else, like local.bak. > > 2. Start mintty in the usual way. > > 3. Rename the directory from step 1 back to /usr/share/local. > > 4. Work just like the problem never existed either in the shell running > > inside the mintty or even start a new mintty. > > >>> > > >>> I guess renaming /usr/share/locale/locale.alias is enough. > > >> > > >> I've had some time to look into this problem again after having updated > > >> Cygwin to the latest and greatest. Indeed, when > > >> > > >> /usr/share/locale/locale.alias > > >> > > >> gets renamed, the problem also goes away. This is great because I don't > > >> really need the locale aliases for anything. Btw, my laptop got > > >> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't > > >> specific to 1803 as was supected earlier. > > >> > > >> I then tried to figure out what exactly causes the problem and it turns > > >> out that it's the _presence_ of this file with the additional condition > > >> that it must not be owned by the user starting the mintty/shell. Since > > >> I install Cygwin on my work laptop with a different (admin) account and > > >> not my (non-admin) user account, that explains why I am seeing the > > >> problem there and not on other machines. Before you are going to > > >> suggest that it's the admin vs. non-admin rights: no, if I create a > > >> locale.alias with my user account (either as an empty file or a copy of > > >> the backup file), then the admin account is unable to start a shell in > > >> mintty successfully. I have no idea why the ownership of a file that > > >> onnly should get read (and is readable by everyone) would have the > > >> effect I'm seeing, but maybe that gives the clue on where to look for a > > >> fix. > > > > > > Thanks for the additional information. I tested the following steps > > > to confirm if the problem can be reproduced. > > > > > > 1. Enable Administrator account. > > > 2. Remove all groups from account yano other than Users. > > > 3. Install cygwin for all with gettext package as Administrator. > > > 4. Run mintty from desktop shortcut as Administrator. > > > 5. Run mintty from desktop shortcut as yano. > > > > > > Both 4 and 5 successfully open mintty window with shell. > > > > > > I wonder what is the difference between my environment and yours. > > > > Locale setting? > > > > fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls > > get_langinfo@2768 calls@2781 > > nlsfuncs.cc(__set_locale_from_locale_alias)@1462 > > which opens /usr/share/locale/locale.alias@1472. > > > > One problem I see with that is that __set_locale_from_locale_alias is meant > > to > > be called when loadlocale fails with an unrecognized locale, but in > > get_langinfo@2778 if the locale is not found, it is defaulted to C before > > __set_locale_from_locale_alias is called, defeating the purpose: > > > > const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale); > > if (!locale) > > locale = "C"; > > > > char tmp_locale[ENCODING_LEN + 1]; > > char *ret = __set_locale_from_locale_alias (locale, tmp_locale); > > if (ret) > > locale = tmp_locale; > > Hmm..., you are right. Furthermore, __set_locale_from_locale_alias() > here is completely unnecessary since it is already processed in > __loadlocale(). No. I was wrong. If locale alias is used, __loadlocale() returns aliased locale. Calling __set_locale_from_locale_alias() is necessary to resolve alias. For example, if locale is set to "japanese", which is defined in /usr/share/locale/locale.alias, __loadlocale() returns "japanese", while __set_locale_from_locale_alias() returns "ja_JP.eucJP". __loadlocale() returns NULL when the alias resolution also fails. So the current code is as designed. -- 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
[ANNOUNCEMENT] Updated: fetchmail-6.4.6-1
The current upstream release of fetchmail is now available on Cygwin as the fetchmail-6.4.6-1 package. The upstream release changelog is here: https://sourceforge.net/projects/fetchmail/files/branch_6.4/ This is the first release that uses the Python3 interpreter as Python2 is now EOL. This release has been compiled with support for NTLM, GSSAPI and Kerberos5 authentication, TLSv1.3 is also available. -- *** 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. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: perl-5.30.3-1
The third maintenance release 5.30.3-1 of Perl is now available on Cygwin. Release notes: https://metacpan.org/changes/release/XSAWYERX/perl-5.30.3 -- *** 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. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: protobuf-3.12.3-1
This is an update to the latest upstream release of protobuf. Protocol Buffers (a.k.a., protobuf) are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. -- *** 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. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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] Test: gnuplot-5.4.rc2-0
Gnuplot release candidate 2 for version 5.4 is now available for testing on Cygwin (you'll have to select the "test" version in order to install it). This is the forerunner of an upstream feature release expected in the upcoming weeks. The upstream release notes are available at: http://www.gnuplot.info/ReleaseNotes_5_4.html Cygwin Notes The tutorial has been removed from the 5.4 branch of gnuplot, so it is no longer available in the package. The ggi terminal has been dropped from the build. I am considering dropping both the gpic and the mif terminal as well. The wxt terminal is now available. The qt terminal still doesn't work on Cygwin due to a Cygwin or Qt5 bug that is still under investigation. If you want to help, please install the gnuplot-qt5 package and try to debug it. The packaging has been changed to allow more control over dependencies. Depending on which packages you install running plain "gnuplot" will dispatch different executables via the alternatives system. There is a bug in the postinstall scripts that defeats the automatic setup of these in the current release which will be fixed in the next release of the package, so you'll need to either run the correct executables directly or fix and re-run the corresponding postinstall/preremove files (either via setup or manually). The gnuplot-base package provides no GUI terminal and will replace the gnuplot package unless you chose to install one of the other feature packages (executable gnuplot-base). The gnuplot-X11 package resembles the previous gnuplot package most closely (the executable is gnuplot-X11). The gnuplot-wx package adds the wxt terminal (and retains the X11 terminal, executable gnuplot-wx) and depends on an extensive list of GNOME libraries. The gnuplot-qt package provites the qt terminal (and retains the X11 terminal, executable gnuplot-qt5) and of course depends on Qt5 libraries. Please note that gnuplot-qt5 does build, but not actually work yet, see above. -- *** 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. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
AltGr key and mintty
According to https://github.com/mintty/mintty/wiki/Keycodes#altgr when the keyboard layout does not have a keycode for an AltGr combination, the AltGr key is treated as Alt instead. I have the following entry in ~/.inputrc "\e'": "`" # Alt+' -> ` and, as AltGr+' is not a valid combination in my keyboard layout, until mintty 3.1.6 by pressing it I was obtaining the wanted backtick character. However, since mintty 3.1.7, this key combination now produces nothing. One has to explicitly use LeftALt+' to obtain the backtick. This is inconvenient because one needs to use both hands, while AltGr+' can be easily triggered with a single hand. -- Enrico -- 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: AltGr key and mintty
Am 07.06.2020 um 13:50 schrieb Enrico Forestieri: According to https://github.com/mintty/mintty/wiki/Keycodes#altgr when the keyboard layout does not have a keycode for an AltGr combination, the AltGr key is treated as Alt instead. There were some recent tweaks to ensure consistent handling of AltGr and right-Alt and I was not aware of that section in the wiki (it was there before my time...). However, I do not reproduce your particular issue: I have the following entry in ~/.inputrc "\e'": "`" # Alt+' -> ` and, as AltGr+' is not a valid combination in my keyboard layout, until mintty 3.1.6 by pressing it I was obtaining the wanted backtick character. However, since mintty 3.1.7, this key combination now produces nothing. Works for me when switching to US keyboard layout. Which layout do you use? One has to explicitly use LeftALt+' to obtain the backtick. That is the proper way now enforced if the right Alt key is in fact AltGr. If it's not, right-Alt+' etc should work alike, as it does here. This is inconvenient because one needs to use both hands, while AltGr+' can be easily triggered with a single hand. -- 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: AltGr key and mintty
On Sun, Jun 07, 2020 at 02:55:25PM +0200, Thomas Wolff wrote: > Am 07.06.2020 um 13:50 schrieb Enrico Forestieri: > > According to > > https://github.com/mintty/mintty/wiki/Keycodes#altgr > > when the keyboard layout does not have a keycode for an AltGr > > combination, the AltGr key is treated as Alt instead. > There were some recent tweaks to ensure consistent handling of AltGr and > right-Alt and I was not aware of that section in the wiki (it was there > before my time...). > However, I do not reproduce your particular issue: > > > I have the following entry in ~/.inputrc > > > > "\e'": "`" # Alt+' -> ` > > > > and, as AltGr+' is not a valid combination in my keyboard layout, > > until mintty 3.1.6 by pressing it I was obtaining the wanted backtick > > character. > > However, since mintty 3.1.7, this key combination now produces nothing. > Works for me when switching to US keyboard layout. Which layout do you use? I am using the IT keyboard layout. > > One has to explicitly use LeftALt+' to obtain the backtick. > That is the proper way now enforced if the right Alt key is in fact AltGr. > If it's not, right-Alt+' etc should work alike, as it does here. All I can say is that it works again when reverting to mintty 3.1.6. -- Enrico -- 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
TCP_KEEPINVTL and TCP_KEEPIDLE - Socket Keep Alives not working
These constants are usually defined in netinet/tcp.h but are not defined anywhere in cygwin. As a result there does not seem to be a way to enable the socket level keep alives in cygwin. One result of this is curl's --keepalive-time option does not work, but it would affect any attempt to enable socket keep alives. Windows' sockets do support keep alives, and indeed the win32 version of curl works correctly. Can someone explain why the TCP keep alive constants are not defined? Is it possible to add this functionality? Where in the cygwin source code does the actual posix socket to winsock translation take place? -- 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: AltGr key and mintty
Am 07.06.2020 um 15:07 schrieb Enrico Forestieri:
On Sun, Jun 07, 2020 at 02:55:25PM +0200, Thomas Wolff wrote:
Am 07.06.2020 um 13:50 schrieb Enrico Forestieri:
According to
https://github.com/mintty/mintty/wiki/Keycodes#altgr
when the keyboard layout does not have a keycode for an AltGr
combination, the AltGr key is treated as Alt instead.
There were some recent tweaks to ensure consistent handling of AltGr and
right-Alt and I was not aware of that section in the wiki (it was there
before my time...).
However, I do not reproduce your particular issue:
I have the following entry in ~/.inputrc
"\e'": "`" # Alt+' -> `
and, as AltGr+' is not a valid combination in my keyboard layout,
until mintty 3.1.6 by pressing it I was obtaining the wanted backtick character.
However, since mintty 3.1.7, this key combination now produces nothing.
Works for me when switching to US keyboard layout. Which layout do you use?
I am using the IT keyboard layout.
The Italian keyboard layout does have an AltGr key:
AltGr+ò → @
AltGr+à → #
AltGr+è → [
AltGr++ → ]
AltGr+é → {
AltGr+* → }
AltGr+' → unmapped by keyboard layout
So the current behaviour is consistent with both the recent changes and
the Italian layout.
However, if people desire, I can add an option to restore the old
AltGr/Alt fallback.
Thomas
One has to explicitly use LeftALt+' to obtain the backtick.
That is the proper way now enforced if the right Alt key is in fact AltGr.
If it's not, right-Alt+' etc should work alike, as it does here.
All I can say is that it works again when reverting to mintty 3.1.6.
--
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] Re: Cygwin setup signing public key update
On 13/03/2020 16:34, Jon Turney wrote: On 13/03/2020 16:13, Jon Turney wrote: This is an announcement of an update to the key used to sign (i) Cygwin setup executables, and (ii) the (compressed) setup.ini package manifest. If you just run setup, and update it when it tells you to update it, no action is required, and this message chain will be of limited interest to you. This update is following the policy announced at [1]: > On 05/08/2008 14:30, Dave Korn wrote: >> If we, from time to time, need to change this key, we will release >> a new version of setup.exe and make announcements on the cygwin >> and cygwin-announce mailing lists, and on the cygwin.com website. Also see that post for further discussion of the technicals details of setup signing. The transition period, during which signatures are made using both keys will probably be approx. 90 days, circumstances permitting. As of today, the signature made is not compatible with setup versions <=2.894, and thus they will no longer work. -- 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: AltGr key and mintty
On Sun, Jun 07, 2020 at 04:42:03PM +0200, Thomas Wolff wrote:
> Am 07.06.2020 um 15:07 schrieb Enrico Forestieri:
> > On Sun, Jun 07, 2020 at 02:55:25PM +0200, Thomas Wolff wrote:
> > > Am 07.06.2020 um 13:50 schrieb Enrico Forestieri:
> > > > According to
> > > > https://github.com/mintty/mintty/wiki/Keycodes#altgr
> > > > when the keyboard layout does not have a keycode for an AltGr
> > > > combination, the AltGr key is treated as Alt instead.
> > > There were some recent tweaks to ensure consistent handling of AltGr and
> > > right-Alt and I was not aware of that section in the wiki (it was there
> > > before my time...).
> > > However, I do not reproduce your particular issue:
> > >
> > > > I have the following entry in ~/.inputrc
> > > >
> > > > "\e'": "`" # Alt+' -> `
> > > >
> > > > and, as AltGr+' is not a valid combination in my keyboard layout,
> > > > until mintty 3.1.6 by pressing it I was obtaining the wanted backtick
> > > > character.
> > > > However, since mintty 3.1.7, this key combination now produces nothing.
> > > Works for me when switching to US keyboard layout. Which layout do you
> > > use?
> > I am using the IT keyboard layout.
> The Italian keyboard layout does have an AltGr key:
> AltGr+ò → @
> AltGr+à → #
> AltGr+è → [
> AltGr++ → ]
> AltGr+é → {
> AltGr+* → }
> AltGr+' → unmapped by keyboard layout
>
> So the current behaviour is consistent with both the recent changes and the
> Italian layout.
I am currently using the following mappings through ~/.inputrc
Alt+' → `
Alt+ì → ~
that mimic the same mapping as on linux (Shift+ì produces ^ by default).
> However, if people desire, I can add an option to restore the old AltGr/Alt
> fallback.
Yes, please, if that's possible. After years of using those key
combinations I always find myself especially using AltGr+ì for
obtainig ~ and discover that it failed only after pressing the
enter key...
--
Enrico
--
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: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN: x86/x86_64 -- perl-Compress-Bzip2-2.27-1 perl-Glib-1.3293-1 perl-Text-CSV_XS-1.43-1 noarch -- perl-CGI-4.48-1 perl-Date-Manip-6.82-1 perl-HTTP-Daemon-6.12-1 perl-Mojolicious-8.52-1 perl-Net-DNS-1.24-1 perl-Test-TrailingSpace-0.0501-1 perl-Test2-Suite-0.000130-1 -- *** 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. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: TCP_KEEPINVTL and TCP_KEEPIDLE - Socket Keep Alives not working
On 6/7/2020 9:20 AM, Cary Lewis via Cygwin wrote: These constants are usually defined in netinet/tcp.h but are not defined anywhere in cygwin. > As a result there does not seem to be a way to enable the socket level keep alives in cygwin. One result of this is curl's --keepalive-time option does not work, but it would affect any attempt to enable socket keep alives. Windows' sockets do support keep alives, and indeed the win32 version of curl works correctly. Can someone explain why the TCP keep alive constants are not defined I'm not an expert on sockets, but I'll just make a couple of comments until Corinna has a chance to give a definitive reply. Cygwin's netinet/tcp.h was derived from the FreeBSD version of the file dated 2000/01/09. It has hardly been touched since it was imported into Cygwin in 2002. FreeBSD didn't add keepalive support until 2012. Is it possible to add this functionality? If you're asking someone else to do it, the question is whether one of the Cygwin developers has the time and expertise to do it. If you're volunteering to do it, patches are always welcome. Where in the cygwin source code does the actual posix socket to winsock translation take place? Cygwin's socket support is in the fhandler_socket* files. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Marked as stable: python-wx-3.0.2.0-5
Version 3.0.2.0-5 of "python2-wx" has been uploaded and is now marked as stable. python2-wx is the Python 2 version of the cross-platform GUI toolkit, wxPython. This revision has the following changes: - Rebuilt against wxWidgets 3.0.4 to fix various issues. - Incorporated new patches from Fedora to fix various issues (including freezing/hangs and graphical glitches) - Used Yaakov's new packaging that separates wxWidgets and wxPython build processes. *** 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. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: TCP_KEEPINVTL and TCP_KEEPIDLE - Socket Keep Alives not working
Thanks very much for the reply - I will wait for Corinna's take on this as well - the patch shouldn't be too hard. In fact the source code for curl in the lib/connect.c file has code to enable the winsock options, so hopefully that code could be helpful. I imagine there must be a translation between the POSIX sockets and winsock in the fhandler_socket. I will attempt to download the cygwin source code - I've never built it, so I don't know how hard it will be. I am surprised that no one else has ever needed the low level TCP keep alives to work. On Sun, Jun 7, 2020 at 2:21 PM Ken Brown via Cygwin wrote: > On 6/7/2020 9:20 AM, Cary Lewis via Cygwin wrote: > > These constants are usually defined in netinet/tcp.h but are not defined > > anywhere in cygwin. > > > > As a result there does not seem to be a way to enable the socket level > keep > > alives in cygwin. > > > > One result of this is curl's --keepalive-time option does not work, but > it > > would affect any attempt to enable socket keep alives. > > > > Windows' sockets do support keep alives, and indeed the win32 version of > > curl works correctly. > > > > Can someone explain why the TCP keep alive constants are not defined > > I'm not an expert on sockets, but I'll just make a couple of comments > until > Corinna has a chance to give a definitive reply. > > Cygwin's netinet/tcp.h was derived from the FreeBSD version of the file > dated > 2000/01/09. It has hardly been touched since it was imported into Cygwin > in > 2002. FreeBSD didn't add keepalive support until 2012. > > > Is it possible to add this functionality? > > If you're asking someone else to do it, the question is whether one of the > Cygwin developers has the time and expertise to do it. If you're > volunteering > to do it, patches are always welcome. > > > Where in the cygwin source code does the actual posix socket to winsock > > translation take place? > > Cygwin's socket support is in the fhandler_socket* files. > > Ken > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- 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-3.1.0 and mintty from desktop shortcut
On 2020-06-07 03:23, Takashi Yano via Cygwin wrote: > On Sun, 7 Jun 2020 16:42:52 +0900 > Takashi Yano via Cygwin wrote: >> On Sun, 7 Jun 2020 00:15:59 -0600 >> Brian Inglis wrote: >>> On 2020-06-06 19:35, Takashi Yano via Cygwin wrote: On Sat, 06 Jun 2020 13:20:16 +0200 ASSI wrote: > Takashi Yano via Cygwin writes: >>> 1. Rename /usr/share/locale to something else, like local.bak. >>> 2. Start mintty in the usual way. >>> 3. Rename the directory from step 1 back to /usr/share/local. >>> 4. Work just like the problem never existed either in the shell running >>> inside the mintty or even start a new mintty. >> >> I guess renaming /usr/share/locale/locale.alias is enough. > > I've had some time to look into this problem again after having updated > Cygwin to the latest and greatest. Indeed, when > > /usr/share/locale/locale.alias > > gets renamed, the problem also goes away. This is great because I don't > really need the locale aliases for anything. Btw, my laptop got > upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't > specific to 1803 as was supected earlier. > > I then tried to figure out what exactly causes the problem and it turns > out that it's the _presence_ of this file with the additional condition > that it must not be owned by the user starting the mintty/shell. Since > I install Cygwin on my work laptop with a different (admin) account and > not my (non-admin) user account, that explains why I am seeing the > problem there and not on other machines. Before you are going to > suggest that it's the admin vs. non-admin rights: no, if I create a > locale.alias with my user account (either as an empty file or a copy of > the backup file), then the admin account is unable to start a shell in > mintty successfully. I have no idea why the ownership of a file that > onnly should get read (and is readable by everyone) would have the > effect I'm seeing, but maybe that gives the clue on where to look for a > fix. Thanks for the additional information. I tested the following steps to confirm if the problem can be reproduced. 1. Enable Administrator account. 2. Remove all groups from account yano other than Users. 3. Install cygwin for all with gettext package as Administrator. 4. Run mintty from desktop shortcut as Administrator. 5. Run mintty from desktop shortcut as yano. Both 4 and 5 successfully open mintty window with shell. I wonder what is the difference between my environment and yours. >>> >>> Locale setting? >>> >>> fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls >>> get_langinfo@2768 calls@2781 >>> nlsfuncs.cc(__set_locale_from_locale_alias)@1462 >>> which opens /usr/share/locale/locale.alias@1472. >>> >>> One problem I see with that is that __set_locale_from_locale_alias is meant >>> to >>> be called when loadlocale fails with an unrecognized locale, but in >>> get_langinfo@2778 if the locale is not found, it is defaulted to C before >>> __set_locale_from_locale_alias is called, defeating the purpose: >>> >>> const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale); >>> if (!locale) >>> locale = "C"; >>> >>> char tmp_locale[ENCODING_LEN + 1]; >>> char *ret = __set_locale_from_locale_alias (locale, tmp_locale); >>> if (ret) >>> locale = tmp_locale; >> >> Hmm..., you are right. Furthermore, __set_locale_from_locale_alias() >> here is completely unnecessary since it is already processed in >> __loadlocale(). > > No. I was wrong. If locale alias is used, __loadlocale() returns > aliased locale. Calling __set_locale_from_locale_alias() is > necessary to resolve alias. For example, if locale is set to > "japanese", which is defined in /usr/share/locale/locale.alias, > __loadlocale() returns "japanese", while > __set_locale_from_locale_alias() returns "ja_JP.eucJP". > > __loadlocale() returns NULL when the alias resolution also fails. > So the current code is as designed. But if __loadlocale() returns a non-NULL string, then the locale and/or alias has been resolved and loaded, so it is unnecessary to further call __set_locale_from_locale_alias(). If __loadlocale() returns a NULL string, then you need to set it to the global default locale "C.ASCII". -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
