Re: HDF5 Installation

2024-03-18 Thread ASSI via Cygwin
Kyle Shores via Cygwin writes:
> Any chance you could use cmake for the next installation? That way more
> packages would be able to include HDF5 with cmake and pkg-config.

That's an upstream issue: the HDF Group still recommends to build with
autotools on UNIX platforms (which Cygwin is most closely aligned to),
but does not provide pkgconfig files in that build yet.  Even with the
cmake build the .pc content was/is incorrect and causes breakage
elsewhere.

https://github.com/HDFGroup/hdf5/issues/8

So if you want to see this in Cygwin, please prod / help upstream to
fix this.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

-- 
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


GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?

2024-03-18 Thread Cedric Blancher via Cygwin
Good morning!

How does cygwin uname -s work, i.e. how does it get the OS version,
revision and build number ('10.0-19045')?
I tried to replicate it via GetVersionEx(), but that is deprecated.

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
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: Getting error 60 of curl to cygwin setup

2024-03-18 Thread Brian Inglis via Cygwin

On 2024-03-18 15:21, J M via Cygwin wrote:

With a fresh install of Cygwin then I launch (with package curl installed):

curl -O https://www.cygwin.com/setup-x86_64.exe

Shows a curl 60 error ssl problem.
Using -k or --insecure works, but is not recomended.
Howto fix it?


WJFFM!

That error implies that the version of curl you are running or the certificate 
store you are using does not include the Let's Encrypt CA used by Cygwin.com.


From what shell do you launch curl?

Please run:

which -a curl

and ensure that /usr/bin/curl precedes /cygdrive/c/WINDOWS/system32/curl then
run:

$ curl -V
curl 8.6.0 (x86_64-pc-cygwin) libcurl/8.6.0 OpenSSL/3.0.13 zlib/1.3.1 
brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.0 
nghttp2/1.60.0 libgsasl/2.2.1 OpenLDAP/2.6.7

Release-Date: 2024-01-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns 
ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli gsasl GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 
Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd


and check you get the same output as above, then run:

cygcheck -c ca-certificates ca-certificates-letsencrypt curl cygwin \
libbrotlidec1 libcurl4 libgsasl18 libgssapi_krb5_2 libidn2_0 libnghttp2_14 \
libopenldap2 libpsl5 libssh2_1 libssl3 libzstd1 zlib0

and ensure all packages show Status OK.

If that is the case, please follow the problem reporting guidelines below, and 
attach the output from running


cygcheck -hrsv > cygcheck-hrsv.log

as a text attachment to your reply.

--
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: HDF5 Installation

2024-03-18 Thread Kyle Shores via Cygwin
Any chance you could use cmake for the next installation? That way more
packages would be able to include HDF5 with cmake and pkg-config.

Best,
Kyle

On Mon, Mar 18, 2024 at 3:23 PM marco atzeri  wrote:

> On Mon, Mar 18, 2024 at 3:28 PM Kyle Shores via Cygwin  wrote:
> >
> > Howdy!
> >
> > Looking at the list of files
> >  >
> > for the 2024 HDF5 installation 1.12.3
> > , I notice that
> > neither the pkg-config or cmake files are installed. For reference,
> > mingw's installation
> > of hdf5  has
> them
> > here:
> >
> >
> >- /mingw64/lib/cmake/hdf5-targets.cmake
> >- /mingw64/lib/pkgconfig/hdf5.pc
> >
> > Are these installed elsewhere? If not, what's preventing them from
> > being installed, or what can I do to help them be installed?
> >
>
> Hi Kyle
>
> the package is NOT built using cmake but is using autoconf.
> There are no special change. So upstream have not included those files
> in the 1.12.3 autoconf
>
> I have not yet tried to build using cmake nor built the 1.14.x series
>
> Regards
> Marco
>

-- 
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


Getting error 60 of curl to cygwin setup

2024-03-18 Thread J M via Cygwin
Hi,

With a fresh install of Cygwin then I launch (with package curl installed):

curl -O https://www.cygwin.com/setup-x86_64.exe

Shows a curl 60 error ssl problem.
Using -k or --insecure works, but is not recomended.
Howto fix it?

Regards,
Cesar Jorge

-- 
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: HDF5 Installation

2024-03-18 Thread marco atzeri via Cygwin
On Mon, Mar 18, 2024 at 3:28 PM Kyle Shores via Cygwin  wrote:
>
> Howdy!
>
> Looking at the list of files
> 
> for the 2024 HDF5 installation 1.12.3
> , I notice that
> neither the pkg-config or cmake files are installed. For reference,
> mingw's installation
> of hdf5  has them
> here:
>
>
>- /mingw64/lib/cmake/hdf5-targets.cmake
>- /mingw64/lib/pkgconfig/hdf5.pc
>
> Are these installed elsewhere? If not, what's preventing them from
> being installed, or what can I do to help them be installed?
>

Hi Kyle

the package is NOT built using cmake but is using autoconf.
There are no special change. So upstream have not included those files
in the 1.12.3 autoconf

I have not yet tried to build using cmake nor built the 1.14.x series

Regards
Marco

-- 
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: Cannot downgrade gcc 13 or 12 to 11.4.0-1

2024-03-18 Thread Jon Turney via Cygwin

On 14/03/2024 18:34, Thomas Hedden via Cygwin wrote:
I installed a test version of gcc and cannot revert to an earlier, 
non-test version. Here are the latest versions listed in the setup routine:


11.4.0-1
12.3.1+20240202-0.1 (Test)
13.2.1+20240203-0.1 (Test)

(there are some even older ones, but I want 11.4.0-1.)

$ gcc --version
gcc (GCC) 13.2.1 20240203

[...]

$ gcc -o hello.exe hello.c
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -lintl: No such file or directory
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -liconv: No such file or directory

collect2: error: ld returned 1 exit status


This seems like a problem with this test version of gcc.  I guess maybe 
it now links with intl and iconv by default in the specsfile, which will 
require the corresponding devel packages to be installed, but it doesn't 
depend on them.


This seems like a mistake. (I think libstdc++ will now require these, 
but they shouldn't be needed just for c compilation.)


So, I can't compile anything. I don't need the test version to work, I 
just want to downgrade to 11.4.0-1. However, if I uninstall the test 
version, and then try to install 11.4.0-1, I get the following message:


Problem 1/1
package gcc-g++-11.4.0-1 requires gcc11, but none of the providers can 
be installed

Solution 1/2
   - allow replacement of gcc-core-13.2.1+20240203-0.1 with 
gcc-core-11.4.0-1

Solution 2/2 (default)
   - do not ask to lock gcc-g++-11.4.0-1

What should I do?


Sorry that this message isn't very clear, and this situation is not 
handled well by setup.


You need to downgrade all the various gcc packages in step.

Which you can do manually, but perhaps the easiest way to do this is to 
select the 'Sync' option at the top-right, which will downgrade all test 
packages.



--
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: ACEs and ACLs

2024-03-18 Thread Corinna Vinschen via Cygwin
On Mar 18 09:23, J. Terry Corbet via Cygwin wrote:
> 
> Sorry, 84-yr old eyes sometimes don't work as well.  Thanks for confirming
> that  nothing has changed with regards to these matters; clearly it is some
> change in the way Windows 11 tries to cooperate with Windows 10 in the case
> of mapped network drives being using in the file sharing mode wherein remote
> users must have ids and passwords on the target drives -- which they do and
> always have, but the key ACE entry known as NT AUTHORITY\Authenticated Users
> is correctly specified after performing an icacls /reset, but is not longer
> correctly set after editing a file with vim across the network.  I'll keep
> looking and trying to  learn.  Thank you.

Please add the "noacl" flag where you need it and try again.  The result
is using the standard Windows security, so you should see what you
expect in that case.


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: ACEs and ACLs

2024-03-18 Thread J. Terry Corbet via Cygwin


Sorry, 84-yr old eyes sometimes don't work as well.  Thanks for 
confirming that  nothing has changed with regards to these matters; 
clearly it is some change in the way Windows 11 tries to cooperate with 
Windows 10 in the case of mapped network drives being using in the file 
sharing mode wherein remote users must have ids and passwords on the 
target drives -- which they do and always have, but the key ACE entry 
known as NT AUTHORITY\Authenticated Users is correctly specified after 
performing an icacls /reset, but is not longer correctly set after 
editing a file with vim across the network.  I'll keep looking and 
trying to  learn.  Thank you.


On 2024-03-18 08:43, Corinna Vinschen via Cygwin wrote:

On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:

Thank you for the greatly needed assistance, but the reference to which you
have pointed me says that noacl will be ignored in the case of ntfs file
systems.

No, it doesn't say that.  It says

   "The flag is ignored on NFS filesystems."
   ^^^
 not NTFS


All of mine are and that has not changed, neither has the default
entry in fstab, which seems always to have been:

none /cygdrive cygdrive binary, posix=0, user 0 0

Well, the code in question hasn't changed for years either.


¯\_(ツ)_/¯
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: ACEs and ACLs

2024-03-18 Thread Corinna Vinschen via Cygwin
On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
> Thank you for the greatly needed assistance, but the reference to which you
> have pointed me says that noacl will be ignored in the case of ntfs file
> systems.

No, it doesn't say that.  It says

  "The flag is ignored on NFS filesystems."
  ^^^
not NTFS

> All of mine are and that has not changed, neither has the default
> entry in fstab, which seems always to have been:
> 
> none /cygdrive cygdrive binary, posix=0, user 0 0

Well, the code in question hasn't changed for years either.


¯\_(ツ)_/¯
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: ACEs and ACLs

2024-03-18 Thread J. Terry Corbet via Cygwin
Thank you for the greatly needed assistance, but the reference to which 
you have pointed me says that noacl will be ignored in the case of ntfs 
file systems.  All of mine are and that has not changed, neither has the 
default entry in fstab, which seems always to have been:


none /cygdrive cygdrive binary, posix=0, user 0 0

On 2024-03-18 04:41, Corinna Vinschen via Cygwin wrote:

On Mar 16 18:05, J. Terry Corbet via Cygwin wrote:

[...]
And here is the status that icacls reports back on the original, owning
workstation
after having use vim to modify the two files from that remote workstation.

FileExp.txt NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
     NW10\tcorbet:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
     NW10\tcorbet:(D,Rc,WDAC,WO,RA,WA)
     NW10\None:(Rc,S,RA)
     NT AUTHORITY\Authenticated Users:(RX,W)
     NT AUTHORITY\SYSTEM:(RX,W)
     BUILTIN\Administrators:(RX,W)
     BUILTIN\Users:(RX)
     Everyone:(Rc,S,RA)

vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
     NW10\tcorbet:(R,W,D,WDAC,WO)
     NW10\None:(DENY)(S,X)
     NT AUTHORITY\Authenticated Users:(DENY)(S,X)
     NT AUTHORITY\SYSTEM:(DENY)(S,X)
     BUILTIN\Administrators:(DENY)(S,X)
     BUILTIN\Users:(DENY)(S,X)
     NW10\None:(RX)
     NT AUTHORITY\Authenticated Users:(RX,W)
     NT AUTHORITY\SYSTEM:(RX,W)
     BUILTIN\Administrators:(RX,W)
     BUILTIN\Users:(RX)
     Everyone:(R)

If my understanding is correct concerning the precedence handling of an
ACL with multiple ACEs for the same user/ID, this result from grep
on the original, owning workstation would not surprise you:

F:\Dev\cygshoot>grep foo fileexp.txt
grep: fileexp.txt: Permission denied

but it blows me completely away.  Clearly I no longer have an environment
in which I can work on any file from any workstation using any Cygwin
utilities.

What have I messed up?

The problem is that your identity is based on the SID of every single
machine, and the machines don't know the SIDs of other machines.  The
default ACL created in Cygwin is emulating POSIX permissions.  This
becomes a problem when sharing files between machines not in the
same Windows domain.

The workaround is not to use POSIX permissions on shares.  Create
matching mount points in /etc/fstab or /etc/fstab.d/ and add the
"noacl" mount flag:

   https://cygwin.com/cygwin-ug-net/using.html#mount-table

Alternatively, you can also just add an fstab entry for the cygdrive
prefix which adds the "noacl" flag, see

   https://cygwin.com/cygwin-ug-net/using.html#cygdrive

but keep in mind that this also affects local paths if you access
them via the cygdrive prefix.


HTH,
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


HDF5 Installation

2024-03-18 Thread Kyle Shores via Cygwin
Howdy!

Looking at the list of files

for the 2024 HDF5 installation 1.12.3
, I notice that
neither the pkg-config or cmake files are installed. For reference,
mingw's installation
of hdf5  has them
here:


   - /mingw64/lib/cmake/hdf5-targets.cmake
   - /mingw64/lib/pkgconfig/hdf5.pc

Are these installed elsewhere? If not, what's preventing them from
being installed, or what can I do to help them be installed?

-- 

Kyle Shores | Software Developer

NSF National Center for Atmospheric Research (NSF NCAR)

Atmospheric Chemistry Observations and Modeling lab (ACOM)

-- 
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: Bogus exit code 127 from a child process

2024-03-18 Thread Alexey Izbyshev via Cygwin

On 2024-03-18 07:58, Takashi Yano wrote:

On Mon, 18 Mar 2024 12:09:06 +0900
Takashi Yano wrote:

On Sun, 17 Mar 2024 14:10:55 +0100
Dimitry Andric wrote:
> On 17 Mar 2024, at 13:50, Dimitry Andric  
wrote:
> >
> > On 17 Mar 2024, at 13:35, Takashi Yano via Cygwin  wrote:
> > ...
> >>
> >> I also test your test case:
> >> while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait -n 
|| { echo 2: $?; exit 1; }'; do echo $((i++)); done
> >> in Linux (Debian 12.5), and the issue reproduced!
> >
> > Yeah, same here with bash 5.1.16(1)-release on Ubuntu 22.04. It errors out 
with 127 after ~50-200 loops.
>
> Having built bash master (bash-5.2-27-gf3b6bd19) here, it consistently gives 
127 in this area:
>
> https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/wait.def#n227
>
>211  #if defined (JOB_CONTROL)
>212if (nflag)
>213  {
>214if (list)
>215  {
>216opt = set_waitlist (list);
>217if (opt == 0)
>218  WAIT_RETURN (127);
>219wflags |= JWAIT_WAITING;
>220  }
>221
>222status = wait_for_any_job (wflags, &pstat);
>223if (vname && status >= 0)
>224  builtin_bind_var_to_int (vname, pstat.pid, bindflags);
>225
>226if (status < 0)
> => 227  status = 127;
>228if (list)
>229  unset_waitlist ();
>230WAIT_RETURN (status);
>231  }
>232  #endif
>
> So for some reason, wait_for_any_job() returns a negative value in this 
particular situation.

Line 218 looks also suspicious.


Probably, this is not a bug. man bash says:
  If  the  -n option is supplied, wait waits for a single 
job from
  the list of ids or, if no ids are supplied, any job, to 
complete
  and returns its exit status.  If none of the supplied  
arguments
  is a child of the shell, or if no arguments are supplied 
and the
  shell  has no unwaited‐for children, the exit status is 
127.


If the background process exited before calling 'wait -n', it returns 
127.

This is very different from wait() system call, which is necessary for
any background joubs, otherwise zombie remains.

In the shell, it is not necessary to call wait command for background 
jobs,
therefore exit status of the background job which already exited is not 
held

anymore.

So, actual bug is in the test case.


I missed the subthread starting from your bash version request due to 
not being CCed, so replying via the mail archive link.


I'm sorry for wasting your time with the bad test case. I should have 
tested on Linux first myself. Thank you, Takashi and Dimitry.


The original problem with make that I was reproducing doesn't involve 
"wait -n" or any bash background jobs though, so this puts me back to 
the point before (I thought) I eliminated make. I'll try my older 
reproducers with new Cygwin versions, and will probably look at make 
source code (since it's starting to look like it might be a bug in make, 
not in Cygwin) before posting further.


Thanks,
Alexey


--
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: ACEs and ACLs

2024-03-18 Thread Corinna Vinschen via Cygwin
On Mar 16 18:05, J. Terry Corbet via Cygwin wrote:
> [...]
> And here is the status that icacls reports back on the original, owning
> workstation
> after having use vim to modify the two files from that remote workstation.
> 
> FileExp.txt NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>     NW10\tcorbet:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
>     NW10\tcorbet:(D,Rc,WDAC,WO,RA,WA)
>     NW10\None:(Rc,S,RA)
>     NT AUTHORITY\Authenticated Users:(RX,W)
>     NT AUTHORITY\SYSTEM:(RX,W)
>     BUILTIN\Administrators:(RX,W)
>     BUILTIN\Users:(RX)
>     Everyone:(Rc,S,RA)
> 
> vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
>     NW10\tcorbet:(R,W,D,WDAC,WO)
>     NW10\None:(DENY)(S,X)
>     NT AUTHORITY\Authenticated Users:(DENY)(S,X)
>     NT AUTHORITY\SYSTEM:(DENY)(S,X)
>     BUILTIN\Administrators:(DENY)(S,X)
>     BUILTIN\Users:(DENY)(S,X)
>     NW10\None:(RX)
>     NT AUTHORITY\Authenticated Users:(RX,W)
>     NT AUTHORITY\SYSTEM:(RX,W)
>     BUILTIN\Administrators:(RX,W)
>     BUILTIN\Users:(RX)
>     Everyone:(R)
> 
> If my understanding is correct concerning the precedence handling of an
> ACL with multiple ACEs for the same user/ID, this result from grep
> on the original, owning workstation would not surprise you:
> 
> F:\Dev\cygshoot>grep foo fileexp.txt
> grep: fileexp.txt: Permission denied
> 
> but it blows me completely away.  Clearly I no longer have an environment
> in which I can work on any file from any workstation using any Cygwin
> utilities.
> 
> What have I messed up?

The problem is that your identity is based on the SID of every single
machine, and the machines don't know the SIDs of other machines.  The
default ACL created in Cygwin is emulating POSIX permissions.  This
becomes a problem when sharing files between machines not in the
same Windows domain.

The workaround is not to use POSIX permissions on shares.  Create
matching mount points in /etc/fstab or /etc/fstab.d/ and add the
"noacl" mount flag:

  https://cygwin.com/cygwin-ug-net/using.html#mount-table

Alternatively, you can also just add an fstab entry for the cygdrive
prefix which adds the "noacl" flag, see

  https://cygwin.com/cygwin-ug-net/using.html#cygdrive

but keep in mind that this also affects local paths if you access
them via the cygdrive prefix.


HTH,
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: Additional odd behavior after my upgrade to the latest CYGWIN64 version

2024-03-18 Thread Corinna Vinschen via Cygwin
On Mar 16 16:49, Michael Goldshteyn via Cygwin wrote:
> Cygwin handles (filename) case insensitivity in a very weird way at the
> Windows command prompt:
> --
> c:\Users\Michael>set CYGWIN=
> 
> c:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a A a A a A
> 
> REM OK, so far so good, but, now:
> c:\Users\Michael>set CYGWIN=glob:ignorecase
> 
> C:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a a a a a A
> 
> REM So, if I don't put a command line arg into any sort of quotes, it gets
> lower-cased for cygwin apps (from the Windows command line).
> REM I should also add that there is no file named 'a' or 'A' in the current
> working directory.
> 
> REM This behavior, of course, doesn't happen in Cygwin bash:
> --
> C:\Users\Michael>bash
> Michael@lambda /cygdrive/c/Users/Michael
> $ echo "$CYGWIN"
> glob:ignorecase
> Michael@lambda /cygdrive/c/Users/Michael
> $ printf "%q " 'a' 'A' "a" "A" a A
> a A a A a A
> $ # Output looks correct, quoted or not
> --
> The unsolicited conversion of case for quoted string is very odd, to say
> the least. If you remove the glob:ignorecase from the CYGWIN env var
> definition, use of filenames on Windows with Cygwin tools becomes
> completely case sensitive, which is very undesirable when compared to the
> fact that other Windows tools do not care about file case (i.e., case
> insensitive, but preserving, as MS puts it).

This was an ill-advised optimization attempt in glob.  I revert the
patch and pushed the change(*), so this will be fixed in Cygwin 3.5.2.

For the time being, you can also test this by installing the just
building Cygwin test release 3.6.0-0.85.g89afbb8d8af2, which should
be available in an hour or two.


Thanks,
Corinna


(*) https://cygwin.com/cgit/newlib-cygwin/commit/?id=70375b2205

-- 
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: Additional odd behavior after my upgrade to the latest CYGWIN64 version

2024-03-18 Thread Andrey Repin via Cygwin
Greetings, Michael Goldshteyn!

> Cygwin handles (filename) case insensitivity in a very weird way at the
> Windows command prompt:
> --
> c:\Users\Michael>set CYGWIN=

> c:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a A a A a A

> REM OK, so far so good, but, now:
> c:\Users\Michael>set CYGWIN=glob:ignorecase

> C:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a a a a a A

Oh, so THAT's what causing my git diff to disappear!

>> [C:\]$ set cyg
>> CYGWIN=wincmdln winsymlinks:native glob:ignorecase
>> CYGWIN_DIR=C:\Programs\Cygwin
>> CYGWIN_MIRROR=https://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin
>>
>> [C:\]$ mintty -- git diff --minimal "--diff-filter=MAD" --find-renames=70 
>> --irreversible-delete HEAD --

>> # The actual executed command is:
>> git diff --minimal --diff-filter=mad --find-renames=70 --irreversible-delete 
>> HEAD --

I don't think that's how it is supposed to work.


-- 
With best regards,
Andrey Repin
Monday, March 18, 2024 12:06:56

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