Automounter in Cygwin to mount NFS home dir on demand ?
Hi! Does Cygwin have something like a Solaris/Linux autofs-style automounter ? The idea is to mount NFS home dirs automagically the first time someone uses them, e.g. $ cd /home/chickenmonster/ # automagically mounts NFS dir mymonsternfs:/export/home/chickenmonster/ Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&& programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- 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
Map home dir drive (H:) to /home/myuser/ ?
Good morning! Does Cygwin have a way to map a (NFS) home dir drive (H:) to /home/myuser/, without resorting to POSIX-style softlinks ([1]) ? Example: 1. Home dir mounted on drive H: via NFS 2. How do I now map H: to /home/myuser/ ? For example Linux and Solaris use the automounter to mount NFS dirs directly to /home/myuser/ , and Solaris uses lofs (loopback filesystem) to mount a local users home dir /export/home/myuser/. Does Cygwin have a similar facility for drives represented by drive letters (e.g. H: [2]) ? [1]=Soft-links should be avoided because they cause confusion/breakage if scripts try to use the physical path (e.g. realpath(1)) [2]=And yes, I am not a Windows guru, and likely use the wrong terms/vocabulary here... ;-(( MfG, Roland Mainz -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&& programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- 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
Entering Cygwin command line (bash login) from Windows cmd.exe ?
Hi! Is there an official way to enter the Cygwin command line (e.g. bash login) from Windows cmd.exe, e.g. if someone ssh's into a Windows machine he/she ends/up in a cmd.exe and not bash... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&& programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- 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] dig and host don't work in IPv6
> Thanks. Unfortunately neither of those options fixes the problem. Sorry... Did you try using the -d option to see what DNS servers these commands try to actually connect to (and time out, eventually). (strace can help as well, I think.) 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: [EXTERNAL] dig and host don't work in IPv6
> > Should I be doing something differently? Or is it a bug? > > It may be sort of a limitation (IIRC, in Cygwin's minires) but: > > Did you try to use > > options=osquery > > and (separate by spaces) / or > > options=inet6 > > in /etc/resolv.conf ? Thanks. Unfortunately neither of those options fixes the problem. And yes, other Cygwin network clients work normally, for example curl and ssh. Andrew -- 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: fnmatch improvements
On Fri, Jul 28, 2023 at 5:12 AM Corinna Vinschen wrote: I'm puzzled because I'm an idiot. > That's one thing you certainly are not. Bill -- 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: GB18030 locale
Corinna Vinschen wrote: > test-fnmatch-5.sh is SKIPped because we don't support zh_CN.GB18030. Hmm? When I read winsup/cygwin/release/3.5.0 and the commit 5da71b6059956a8f20a6be02e82867aa28aa3880, it seems the zh_CN.GB18030 locale (which on native Windows is called "Chinese_China.54936") should be supported. The Gnulib code which determines whether this locale is supported is in m4/locale-zh.m4. Why does the "checking for a transitional chinese locale..." test fail on your system, when you call it as LC_ALL=zh_CN.GB18030 LC_TIME= LC_CTYPE= ./conftest ? Bruno -- 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: fnmatch improvements
Corinna Vinschen wrote: > > 1. cd testdir-fnmatch-posix > > ./configure > > grep REPLACE_FNMATCH config.status > > (Expected: REPLACE_FNMATCH is 0) > > $ grep REPLACE_FNMATCH config.status > S["REPLACE_FNMATCH"]="0" > > > make > > make check > > (Expected: No test failures) > > # TOTAL: 218 > # PASS: 178 > # SKIP: 40 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > > test-fnmatch-5.sh is SKIPped because we don't support zh_CN.GB18030. > > > cd .. > > 2. cd testdir-fnmatch-gnu > > ./configure > > grep REPLACE_FNMATCH config.status > > (Expected: REPLACE_FNMATCH is 1, because of FNM_EXTMATCH) > > $ grep REPLACE_FNMATCH config.status > S["REPLACE_FNMATCH"]="1" > > > make > > make check > > (Expected: No test failures) > > # TOTAL: 218 > # PASS: 178 > # SKIP: 40 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > > Same SKIP of test-fnmatch-5.sh. > > Does that look ok? Yes, that's all OK and as expected. I'll commit the fnmatch.m4 patch today. When the user asks for an fnmatch() with FNM_EXTMATCH support, they will get the Gnulib fnmatch(), as it supports these GNU extensions. I'll think about how to make [=X=] and [.X.] work in this case too... Thank you for your constructive cooperation! Bruno -- 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: [PATCH 5/5] Cygwin: add AT_EMPTY_PATH fix to release message
On Jul 28 17:11, Pedro Alves wrote: > On 2023-07-12 13:08, Corinna Vinschen wrote: > > +- Fix AT_EMPTY_PATH handling in fchmodat and fstatat if dirfd referres to > > referres -> refers Oops, sorry, too late :}
Re: fnmatch improvements
On Jul 28 12:56, Bruno Haible via Cygwin wrote: > It's sometimes hard to make incremental changes to generated files of the > GNU Build System plus Gnulib. I've therefore recreated a new tarball for you, > at https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz . > > The expected result is: > 1. cd testdir-fnmatch-posix > ./configure > grep REPLACE_FNMATCH config.status > (Expected: REPLACE_FNMATCH is 0) $ grep REPLACE_FNMATCH config.status S["REPLACE_FNMATCH"]="0" > make > make check > (Expected: No test failures) # TOTAL: 218 # PASS: 178 # SKIP: 40 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 test-fnmatch-5.sh is SKIPped because we don't support zh_CN.GB18030. > cd .. > 2. cd testdir-fnmatch-gnu > ./configure > grep REPLACE_FNMATCH config.status > (Expected: REPLACE_FNMATCH is 1, because of FNM_EXTMATCH) $ grep REPLACE_FNMATCH config.status S["REPLACE_FNMATCH"]="1" > make > make check > (Expected: No test failures) # TOTAL: 218 # PASS: 178 # SKIP: 40 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Same SKIP of test-fnmatch-5.sh. Does that look ok? Thanks, Corinna -- 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] dig and host don't work in IPv6
> It may be sort of a limitation (IIRC, in Cygwin's minires) but:
> > Should I be doing something differently? Or is it a bug?
> > the host and dig commands no longer work
Reading your question again, I don't think Cygwin's minires limitation (if any)
can be at play here because IIRC neither dig nor host (as actually a
specialization of dig) use the resolver API but work directly at the DNS
protocol level...
OTOH, they probably are looking at the nsaddr section of the resolver context
structure to see what INET6 nameservers are available -- and they don't see any
in there, that's why they fail?..
These are just my assumptions, though.
Are your [other] applications (that use the resolver API, with the osquery
option, as suggested previously) able to resolve IPv6 addresses?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
Cygwin's /usr/include/resolv.h has only IPv4 entries for nameservers:
struct __res_state {
int retrans;/* retransmition time interval */
int retry; /* number of times to retransmit */
u_long options;/* option flags - see below. */
int nscount;/* number of name servers */
struct sockaddr_in
nsaddr_list[MAXNS]; /* address of name server */
// <<<=== IPv4 only
#define nsaddr nsaddr_list[0] /* for backward compatibility */
u_short id; /* current message id */
char*dnsrch[MAXDNSRCH+1]; /* components of domain to search */
chardefdname[256]; /* default domain (deprecated) */
u_long pfcode; /* RES_PRF_ flags - see below. */
unsigned ndots:4; /* threshold for initial abs. query */
unsigned nsort:4; /* number of elements in sort_list[] */
charunused[3];
struct {
struct in_addr addr;
u_int32_t mask;
} sort_list[MAXRESOLVSORT];
res_send_qhook qhook; /* query hook */
res_send_rhook rhook; /* response hook */
int res_h_errno;/* last one set for this context */
int _vcsock;/* PRIVATE: for res_send VC i/o */
u_int _flags; /* PRIVATE: see below */
union {
/* On an 32-bit arch this means 512b total. */
charpad[72 - 3*sizeof (int) - 2*sizeof (void *)];
struct {
u_int16_t nscount;
u_int16_t nstimes[MAXNS]; /* ms. */
int nssocks[MAXNS];
struct __res_state_ext *ext;/* extention for IPv6 */
} _ext;
} _u;
};
--
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] dig and host don't work in IPv6
> Should I be doing something differently? Or is it a bug? It may be sort of a limitation (IIRC, in Cygwin's minires) but: Did you try to use options=osquery and (separate by spaces) / or options=inet6 in /etc/resolv.conf ? 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: [PATCH 5/5] Cygwin: add AT_EMPTY_PATH fix to release message
On 2023-07-12 13:08, Corinna Vinschen wrote: > +- Fix AT_EMPTY_PATH handling in fchmodat and fstatat if dirfd referres to referres -> refers
dig and host don't work in IPv6
Our agency has started using IPv6. My PC has IPv4 and IPv6 addresses. DNS servers are all IPv6 addresses. All of this works great, except that now the host and dig commands no longer work, even with -6: $ dig -6 cygwin.com ; <<>> DiG 9.11.9 <<>> -6 cygwin.com ;; global options: +cmd ;; connection timed out; no servers could be reached It does work if I specify the DNS server in the command: $ dig @2620:117:5010:1a1::f005 cygwin.com ; <<>> DiG 9.11.9 <<>> @2620:117:5010:1a1::f005 cygwin.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56580 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1220 ; COOKIE: d078f7e381ceee2117dbf35864c3e4d5b7b37dc8c646f48c (good) ;; QUESTION SECTION: ;cygwin.com.IN A ;; ANSWER SECTION: cygwin.com. 3600IN A 8.43.85.97 ;; Query time: 142 msec ;; SERVER: 2620:117:5010:1a1::f005#53(2620:117:5010:1a1::f005) ;; WHEN: Fri Jul 28 11:55:01 EDT 2023 ;; MSG SIZE rcvd: 83 It also works if I manually add a 'nameserver' line to /etc/resolv.conf. That's not a sustainable solution though, since the nameservers change and I drop into and out of the IPv6 VPN. Should I be doing something differently? Or is it a bug? Thanks, Andrew -- 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: error report
>bin/iperf3.exe -c 192.168.1.233 -P 1 -i 1 -p 5201 -f g -t 10   0 [main] >iperf3 17636 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. >Please report this problem tothe public mailing list cygwin@cygwin.com https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- 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
error report
bin/iperf3.exe -c 192.168.1.233 -P 1 -i 1 -p 5201 -f g -t 10 0 [main] iperf3 17636 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem tothe public mailing list cygwin@cygwin.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: chattr makes cygport slow
> On 16/07/2023 20:32, ASSI via Cygwin-apps wrote: > > Jon Turney via Cygwin-apps writes: > >> The warning (error if RESTRICT=case_insensitive) should occur for all > >> commands, not just prep. > > > > OK. > > > >> How about the attached. > > > > Looks promising. > > Ok. I made a cygport 0.36.6 release with this change. > > Please let me know if it makes things better (or worse!)? So much better. Thank you. Andrew
Re: fnmatch improvements
Corinna Vinschen wrote: > I'm puzzled because I'm an idiot. I forgot autoreconf. Things like that happen to me as well. There are so many generation phases (collect *.m4 files; autoconf; configure; make) that it's easy to forget one when making incremental changes. It's more reliable to regenerate the testdir from scratch. Bruno -- 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: fnmatch improvements
On Jul 28 12:56, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > After the above fail, I tried from scratch with your below patch, > > and I still get > > > > $ grep REPLACE_FNMATCH ./config.status > > S["REPLACE_FNMATCH"]="1" > > > > Even though > > > > $ grep fnmatch log1 > > checking for fnmatch.h... yes > > checking for fnmatch... yes > > checking for working POSIX fnmatch... yes > > > > I'm quite puzzled. > > It's sometimes hard to make incremental changes to generated files of the > GNU Build System plus Gnulib. I've therefore recreated a new tarball for you, > at https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz . Thanks, I'll use that for testing later today. Corinna -- 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: fnmatch improvements
On Jul 28 10:53, Corinna Vinschen via Cygwin wrote: > On Jul 27 23:40, Bruno Haible via Cygwin wrote: > > Corinna Vinschen wrote: > > > S["REPLACE_FNMATCH"]="1" > > > > > > Looks like the reason is that we don't have a uchar.h file? Seems > > > like this is of interest for AIX, but why should this be of > > > interest for fnmatch on other systems? > > > > Ah, that's because I made the assumption that if wchar_t is only 16-bits > > wide, fnmatch() can't be correct. Which is true for AIX (and on this > > platform, I prefer not to test the available locales). But not true > > with your implementation any more. > > > > What are the test suite results if you do > > > > - Replace S["REPLACE_FNMATCH"]="1" with S["REPLACE_FNMATCH"]="0" > > in config.status, > > - make clean > > - ./config.status > > - make > > The build fails here. The reason is that the GNU extension FNM_EXTMATCH > is not supported by the FreeBSD code base of fnmatch, so it's not > defined in our fnmatch.h system header. Gnulib still tries to build > fnmatch_loop.c which uses FNM_EXTMATCH, but apparently it now relies on > using the system header? > [...] > After the above fail, I tried from scratch with your below patch, > and I still get > > $ grep REPLACE_FNMATCH ./config.status > S["REPLACE_FNMATCH"]="1" > > Even though > > $ grep fnmatch log1 > checking for fnmatch.h... yes > checking for fnmatch... yes > checking for working POSIX fnmatch... yes > > I'm quite puzzled. I'm puzzled because I'm an idiot. I forgot autoreconf. After that and another configure run, REPLACE_FNMATCH is correctly set to 0 *and* the build runs fine. I'll do the rest of the test later today. Sorry, Corinna -- 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: fnmatch improvements
Corinna Vinschen wrote: > After the above fail, I tried from scratch with your below patch, > and I still get > > $ grep REPLACE_FNMATCH ./config.status > S["REPLACE_FNMATCH"]="1" > > Even though > > $ grep fnmatch log1 > checking for fnmatch.h... yes > checking for fnmatch... yes > checking for working POSIX fnmatch... yes > > I'm quite puzzled. It's sometimes hard to make incremental changes to generated files of the GNU Build System plus Gnulib. I've therefore recreated a new tarball for you, at https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz . The expected result is: 1. cd testdir-fnmatch-posix ./configure grep REPLACE_FNMATCH config.status (Expected: REPLACE_FNMATCH is 0) make make check (Expected: No test failures) cd .. 2. cd testdir-fnmatch-gnu ./configure grep REPLACE_FNMATCH config.status (Expected: REPLACE_FNMATCH is 1, because of FNM_EXTMATCH) make make check (Expected: No test failures) cd .. Bruno -- 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: fnmatch improvements
On Jul 28 11:00, Corinna Vinschen via Cygwin wrote: > If we do that, I think the functions > should actually be renamed accordingly and the globbing code should use > uchar32_t rather than wint_t. s/uchar32_t/char32_t/ -- 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: fnmatch improvements
On Jul 27 16:17, Brian Inglis via Cygwin wrote: > On 2023-07-27 15:22, Bruno Haible wrote: > > Brian Inglis wrote: > > > It was added in C99 TR19769, integrated in C/++11 > > > > Yes. > > > > > available in libicu-devel: > > > > > > https://cplusplus.com/reference/cuchar/ > > > > > > https://open-std.org/jtc1/sc22/open/n3579.pdf > > > > > > https://open-std.org/jtc1/sc22/wg14/www/docs/n1326.pdf > > > > > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#page=416 > > > > > > $ find /usr/include/ -name uchar.h > > > /usr/include/unicode/uchar.h > > > > > > $ cygcheck -f /usr/include/unicode/uchar.h > > > libicu-devel-72.1-1 > > > > This file, from ICU4C, is something completely different > > than > > ISO C's . > > This would then be a *newlib* AT sourceware DOT org addition so we could use > FreeBSD's: We can use FreeBSDs version as role model, but we can't use the code verbatim, given FreeBSD assumes sizeof(wchar_t) == 4. Since that's a Cygwin-only issue (2 byte wchar_t, that is), I guess we should merge the code into the Cygwin code base, rather than newlib. For mbrtoc32/c32rtomb, we can use the wirtomb/mbrtowi function I introduced for the globbing code. If we do that, I think the functions should actually be renamed accordingly and the globbing code should use uchar32_t rather than wint_t. Also, it might be helpful to add the mbrtoc8/c8rtomb extensions at one point, which are missing in FreeBSD. Either way, I'd be grateful for patches in this area. Corinna -- 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: fnmatch improvements
On Jul 27 23:40, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > > 4. cd testdir-fnmatch-posix > > > > ./configure 2>&1 | tee log1 > > > > make > > > > make check > > > > I fixed the above problem and the POSIX check now works fine: > > Glad that the test suite was helpful (and that you fixed it before 3.5.0 — > so, no additional configure tests needed on the gnulib side). > > > > > grep fnmatch log1 > > > > checking for fnmatch.h... yes > > checking for fnmatch... yes > > checking for working POSIX fnmatch... yes > > > > I also extraced the fnmatch configure testcase and ran it manually. > > It returns 0 now. But: > > > > > > grep REPLACE_FNMATCH config.status > > > > S["REPLACE_FNMATCH"]="1" > > > > Looks like the reason is that we don't have a uchar.h file? Seems > > like this is of interest for AIX, but why should this be of > > interest for fnmatch on other systems? > > Ah, that's because I made the assumption that if wchar_t is only 16-bits > wide, fnmatch() can't be correct. Which is true for AIX (and on this > platform, I prefer not to test the available locales). But not true > with your implementation any more. > > What are the test suite results if you do > > - Replace S["REPLACE_FNMATCH"]="1" with S["REPLACE_FNMATCH"]="0" > in config.status, > - make clean > - ./config.status > - make The build fails here. The reason is that the GNU extension FNM_EXTMATCH is not supported by the FreeBSD code base of fnmatch, so it's not defined in our fnmatch.h system header. Gnulib still tries to build fnmatch_loop.c which uses FNM_EXTMATCH, but apparently it now relies on using the system header? > - make check > > Then the tests will be run against Cygwin's fnmatch() function. > If all tests pass, I will add the following patch to gnulib. After the above fail, I tried from scratch with your below patch, and I still get $ grep REPLACE_FNMATCH ./config.status S["REPLACE_FNMATCH"]="1" Even though $ grep fnmatch log1 checking for fnmatch.h... yes checking for fnmatch... yes checking for working POSIX fnmatch... yes I'm quite puzzled. Corinna > > diff --git a/m4/fnmatch.m4 b/m4/fnmatch.m4 > index 2e1442eff7..e99737a476 100644 > --- a/m4/fnmatch.m4 > +++ b/m4/fnmatch.m4 > @@ -1,4 +1,4 @@ > -# Check for fnmatch - serial 18 -*- coding: utf-8 -*- > +# Check for fnmatch - serial 19 -*- coding: utf-8 -*- > > # Copyright (C) 2000-2007, 2009-2023 Free Software Foundation, Inc. > # This file is free software; the Free Software Foundation > @@ -14,7 +14,7 @@ AC_DEFUN([gl_FUNC_FNMATCH_POSIX] >m4_divert_text([DEFAULTS], [gl_fnmatch_required=POSIX]) > >AC_REQUIRE([gl_FNMATCH_H]) > - AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles > + AC_REQUIRE([AC_CANONICAL_HOST]) >gl_fnmatch_required_lowercase=` > echo $gl_fnmatch_required | LC_ALL=C tr '[[A-Z]]' '[[a-z]]' >` > @@ -164,7 +164,17 @@ AC_DEFUN([gl_FUNC_FNMATCH_POSIX] > dnl This is due to wchar_t being only 16 bits wide. > AC_REQUIRE([gl_UCHAR_H]) > if test $SMALL_WCHAR_T = 1; then > - REPLACE_FNMATCH=1 > + case "$host_os" in > +cygwin*) > + dnl On Cygwin < 3.5.0, the above $gl_fnmatch_result came out as > 'no', > + dnl On Cygwin >= 3.5.0, fnmatch supports all Unicode characters, > + dnl despite wchar_t being only 16 bits wide (because internally it > + dnl works on wint_t values). > + ;; > +*) > + REPLACE_FNMATCH=1 > + ;; > + esac > fi >fi >if test $HAVE_FNMATCH = 0 || test $REPLACE_FNMATCH = 1; then > > > > > -- > 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
