Can util-linux 2.33.1-3 come out of [test] ?

[Bruce Jerrick via Cygwin]

util-linux 2.33.1-3 depends on cygwin >= 3.5.0 .  The latter has come
out of test, so can util-linux 2.33.1-3 also come out of test?

-- 
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp via Cygwin]

On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
 wrote:
>
> The behaviour changed in 2020
>
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
>
> not without a discussion
>
> https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html

Aha, thank you! (congrats on the 3.5 release, in passing, btw).
Definitely not a regression, then (subject edited).

However, this patch came from MSYS2, and subsequently they seem to
have found it problematic for the same reason as me
(https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
and have just recently reintroduced the flag
(https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
to control it.

The reasoning in
https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
valid now as it did in 2006.

Is it possible to revisit having the flag, or even just reverting the behaviour?

FWIW, it's been "hurting" us over in OCaml-land since zstd support was
added roughly a year ago - configure can tell us that mingw-w64's zstd
is available, but woe betide us if we run the test program to see if
it actually works, but the user forgot to add the sys-root into PATH,
because at that point the CI system is down...

Thanks,


David

-- 
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: ipython failing after last python code update.

[marco atzeri via Cygwin]

On Fri, Feb 2, 2024 at 11:34 AM Emilio Rojas via Cygwin  wrote:
>
> I've attached the cygcheckout.out file.
>
> python3.9.18 seems to work fine, but when I run ipython8.18.1 it hangs
> after tying any command.
>

Hi Emilio,
you are in the right place.

Others have reported similar problems on other python packages

https://cygwin.com/pipermail/cygwin/2024-January/255273.html
https://cygwin.com/pipermail/cygwin/2024-January/255267.html

and going back to 3.9,16-1 solved their issue.

Can you confirm that using previous version python 3.9.16-1 you have
no problem ?

The easy way to replace python39 version 3.9.18-1 with version
3.9.16-1 is to select "Sync" at the Package selection window

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

VULNERABILITY REPORT: DLL Hijacking Vulnerability in CygWin setup-x86_64.exe

[Suman Chakraborty via Cygwin]

Hey Cygwin Team,

I hope this email finds you well. As an independent security researcher, I
often explore open-source projects to identify and report potential
security vulnerabilities. During my recent exploration of Cygwin, I came
across a critical vulnerability in setup-x86_64.exe
 that I believe warrants your
immediate attention.

1. Executive Summary:

The vulnerability pertains to not finding the profapi.dll and insecure
loading of dynamic link libraries (DLLs), specifically profapi.dll. If
exploited, this vulnerability could allow an attacker to execute arbitrary
code on a victim's machine, potentially leading to data breaches, system
compromise, and other malicious activities.

2. Details of the Vulnerability:

Type: DLL Hijacking
Affected Component: profapi.dll
Impact: Remote Code Execution, Data Theft or
Manipulation, Persistence, Bypassing Security Mechanisms, Spreading Malware.
Description: The application attempts to load profapi.dll from its current
working directory (CWD). If a malicious version of test.dll is present in
the CWD, the application will inadvertently load and execute the malicious
DLL.

3. Proof of Concept:

I've attached a proof of concept to this email, demonstrating the
vulnerability in action. Please review it to understand the potential
impact and exploitability.
The link is given below:
POC Video:
https://drive.google.com/file/d/11rBPnImiZS-CEwPM9eBlU6GSHjHYD2ns/view?usp=sharing

4. Conclusion:
The identified DLL Hijacking vulnerability poses a significant risk to
users of Cygwin during the installation and executing the setup-x86_64.exe
. I urge you to address this issue
promptly. I'm available for any further clarification or assistance in
addressing the vulnerability

Thank you for your attention to this matter, and I appreciate the hard work
you put into maintaining and improving open-source projects for the
community.Best regards,
Submitted by:
Suman Kumar Chakraborty
LinkedIn:https://www.linkedin.com/in/suman-chakraborty-b857901b1/

-- 
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Jon Turney via Cygwin]

On 02/02/2024 12:55, Corinna Vinschen via Cygwin wrote:

On Feb  2 09:43, David Allsopp via Cygwin wrote:

On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
 wrote:


The behaviour changed in 2020

https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912

not without a discussion

https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html


Aha, thank you! (congrats on the 3.5 release, in passing, btw).
Definitely not a regression, then (subject edited).

However, this patch came from MSYS2, and subsequently they seem to
have found it problematic for the same reason as me
(https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
and have just recently reintroduced the flag
(https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
to control it.

The reasoning in
https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
valid now as it did in 2006.

Is it possible to revisit having the flag, or even just reverting the behaviour?

FWIW, it's been "hurting" us over in OCaml-land since zstd support was
added roughly a year ago - configure can tell us that mingw-w64's zstd
is available, but woe betide us if we run the test program to see if
it actually works, but the user forgot to add the sys-root into PATH,
because at that point the CI system is down...


I'm sympathetic, and personally I would prefer to revert the patch and
stick to SEM_FAILCRITICALERRORS by default.

The question is this: Why does, apparently, everybody expect Cygwin to
do the "right thing", with different definitions of "right", when in
fact the executable in question can easily call SetErrorMode by itself?


Yeah, if cygwin wasn't involved in the process ancestry, how would you 
get the behaviour you want?


I guess perhaps what's needed here is a command-wrapper tool like 'nice' 
or 'env' which lets you run a command with the error-handling mode you want.


But that must already exist for Windows, right? :)


--
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp via Cygwin]

Jon Turney via Cygwin wrote:

> > I'm sympathetic, and personally I would prefer to revert the patch and
> > stick to SEM_FAILCRITICALERRORS by default.
> >
> > The question is this: Why does, apparently, everybody expect Cygwin to
> > do the "right thing", with different definitions of "right", when in
> > fact the executable in question can easily call SetErrorMode by itself?
>
> Yeah, if cygwin wasn't involved in the process ancestry, how would you
> get the behaviour you want?

Ah, but that's how I hit this (and started digging further) -
precisely because the non-Cygwin program I'm using _has_ called
SetErrorMode and its direct calls to the faulty program _are_ doing
what's wanted (no popup dialog) but the calls which happen via Cygwin
are then torching that preference.

Not really suggesting it be done this way (it feels more complicated
than just reverting the change), but in some ways perhaps Cygwin
should be using GetErrorMode on startup and instead of not inheriting
it, ensuring that it sets whatever it received? i.e. just before the
call to CreateProcess for a non-Cygwin binary, Cygwin restores the
error mode (for that thread only) to the value read at startup, calls
CreateProcess and then sets the error mode back.

To explain in the context of the actual call chain:
- I have opam.exe (compiled with mingw-w64), which is calling
SetErrorMode in main
- It's calling ocamlc.exe (in PATH) which requires the zstd DLL, but
that has not been put in PATH
- A direct call - not via Cygwin - to ocamlc -vnum therefore returns
an exit code
- Another call, already there from the Unix side, instead does sh -c
"ocamlc -config | sed ..." but Cygwin has then _removed_ the
calling applications preference

Thanks,


David

-- 
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 09:43, David Allsopp via Cygwin wrote:
> On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
>  wrote:
> >
> > The behaviour changed in 2020
> >
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
> >
> > not without a discussion
> >
> > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
> 
> Aha, thank you! (congrats on the 3.5 release, in passing, btw).
> Definitely not a regression, then (subject edited).
> 
> However, this patch came from MSYS2, and subsequently they seem to
> have found it problematic for the same reason as me
> (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
> and have just recently reintroduced the flag
> (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
> to control it.
> 
> The reasoning in
> https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
> valid now as it did in 2006.
> 
> Is it possible to revisit having the flag, or even just reverting the 
> behaviour?
> 
> FWIW, it's been "hurting" us over in OCaml-land since zstd support was
> added roughly a year ago - configure can tell us that mingw-w64's zstd
> is available, but woe betide us if we run the test program to see if
> it actually works, but the user forgot to add the sys-root into PATH,
> because at that point the CI system is down...

I'm sympathetic, and personally I would prefer to revert the patch and
stick to SEM_FAILCRITICALERRORS by default.

The question is this: Why does, apparently, everybody expect Cygwin to
do the "right thing", with different definitions of "right", when in
fact the executable in question can easily call SetErrorMode by itself?


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: Perl/CPAN Keeps failing [SOLVED]

[Simon Matthews via Cygwin]

Replying to my own email:

On 1/29/24 11:04, Simon Matthews wrote:

I keep getting errors when trying to install Perl packages using CPAN.
I can see some quite old discussions that appear to say that the
problem is solved by mounting the .cpan directory in binmode, but the
options in that solution given to the mount command are not accepted.
I have deleted my .cpan directory and tried multiple times.

Error:

cpan[1]> install Verilog::Netlist
Reading '/home/build/.cpan/sources/authors/01mailrc.txt.gz'
DONE

Reading '/home/build/.cpan/sources/modules/02packages.details.txt.gz'
Warning: Your
/home/build/.cpan/sources/modules/02packages.details.txt.gz does not
contain a Line-Count header.
Please check the validity of the index file by comparing it to more
than one CPAN mirror. I'll continue but problems seem likely to
happen.
Warning: Your
/home/build/.cpan/sources/modules/02packages.details.txt.gz does not
contain a Last-Updated header.
Please check the validity of the index file by comparing it to more
than one CPAN mirror. I'll continue but problems seem likely to
happen.
.Could not split
line["`\cOF_??l???\\?G?k??4??\$2Y`N??,??o???H%?Xr?q??\c\\\cT?e???vM]m??-^?o?/?v???d?-\cO?8Ts?r~??VKkiZ?*F??\cS?;?.y!??w?w?\c?\cM"]
Could not split
line["2\cS???;??i{j?/?\cD???o7???!o???d?dn??eZ???K?\cF?K?3?\cPmm\c^l?,?\cD\e(??\cBwQ?\c^\cM"]
Could not split
line["??\c\\D}?\@F?gY?\cDSg\cPn\cNG??\@?M}8;??d??\cR???F?\\???:??\cYB?#?<\cR\cUD??'?\cE??P?Z??1wg+?6dg?\c]IBX?i?x8?Gz?\cM"]
Could not split
line["\c]???\cH?\e\cR7!b\c@??&???hu?+?7lc?\cR;?>\c_*?&??r??7??9R???C\c]\cV\cR^?\cY\e?\cHm???\cRz+#??\cA]?\cO\c@\c@ms?0\cP??J???osmW^?h?\cK?\cM"]
Giving up parsing your
/home/build/.cpan/sources/modules/02packages.details.txt.gz, too many
errorsReading '/home/build/.cpan/sources/authors/01mailrc.txt.gz'
DONE


Claimed solution here:

https://cygwin.com/pipermail/cygwin/2005-February/129418.html

but the mount no longer accepts  any of the options "-s", "-b" or "-u"

Suggestions on how to deal with this?




The suggestion to mount the .cpan directory in binmode was the solution.
Previous descriptions of this referenced syntax for the mount command
which is no longer valid.

I created a directory c:\CPAN.

I then added the following to /etc/fstab:

c:/cpan /home/build/.cpan ntfs binary 0 0

and ran "mount -a". After this, I was able to successfully run cpan.

Blue Pearl Software, Inc. will collect and process information about you that 
may be subject to data protection laws. For more information about how we use 
and disclose your personal information, how we protect your information, our 
legal basis to use your information, your rights and who you can contact, 
please refer to the relevant sections of our Privacy note at 
www.bluepearlsoftware.com/privacypolicy.

--
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp via Cygwin]

On Fri, 2 Feb 2024 at 12:55, Corinna Vinschen via Cygwin wrote:
> On Feb  2 09:43, David Allsopp via Cygwin wrote:
> > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
> >  wrote:
> > >
> > > The behaviour changed in 2020
> > >
> > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
> > >
> > > not without a discussion
> > >
> > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
> >
> > Aha, thank you! (congrats on the 3.5 release, in passing, btw).
> > Definitely not a regression, then (subject edited).
> >
> > However, this patch came from MSYS2, and subsequently they seem to
> > have found it problematic for the same reason as me
> > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
> > and have just recently reintroduced the flag
> > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
> > to control it.
> >
> > The reasoning in
> > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
> > valid now as it did in 2006.
> >
> > Is it possible to revisit having the flag, or even just reverting the 
> > behaviour?
> >
> > FWIW, it's been "hurting" us over in OCaml-land since zstd support was
> > added roughly a year ago - configure can tell us that mingw-w64's zstd
> > is available, but woe betide us if we run the test program to see if
> > it actually works, but the user forgot to add the sys-root into PATH,
> > because at that point the CI system is down...
>
> I'm sympathetic, and personally I would prefer to revert the patch and
> stick to SEM_FAILCRITICALERRORS by default.
>
> The question is this: Why does, apparently, everybody expect Cygwin to
> do the "right thing", with different definitions of "right", when in
> fact the executable in question can easily call SetErrorMode by itself?

The executable can't, though (at least, I'm not aware that it can)?
The DLL not found case is being triggered by the loader, before the
entrypoint code is running?

I did have a look to see if there are manifest flags or some such
which can be set to indicate this, but it does seem to be the
responsibility of the caller, coupled with a "best practice"
recommendation on MSDN to call SetErrorMode (as Cygwin is of course
doing).

The whole system with it feels like unfortunate Windows legacy, but I
guess the behaviour vastly predates Event Viewer, etc., and slightly
better (and non-blocking) ways of reporting loader errors. Perils of a
nearly 40 year old API, if not OS 

Thanks,


David

-- 
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 13:35, David Allsopp via Cygwin wrote:
> Jon Turney via Cygwin wrote:
> 
> > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > stick to SEM_FAILCRITICALERRORS by default.
> > >
> > > The question is this: Why does, apparently, everybody expect Cygwin to
> > > do the "right thing", with different definitions of "right", when in
> > > fact the executable in question can easily call SetErrorMode by itself?
> >
> > Yeah, if cygwin wasn't involved in the process ancestry, how would you
> > get the behaviour you want?
> 
> Ah, but that's how I hit this (and started digging further) -
> precisely because the non-Cygwin program I'm using _has_ called
> SetErrorMode and its direct calls to the faulty program _are_ doing
> what's wanted (no popup dialog) but the calls which happen via Cygwin
> are then torching that preference.
> 
> Not really suggesting it be done this way (it feels more complicated
> than just reverting the change), but in some ways perhaps Cygwin
> should be using GetErrorMode on startup and instead of not inheriting
> it, ensuring that it sets whatever it received? i.e. just before the
> call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> error mode (for that thread only) to the value read at startup, calls
> CreateProcess and then sets the error mode back.

This sounds like a good ide, but...

Is it actually a safe bet that the error mode set by SetThreadErrorMode
is then propagated as process error mode to the child process?

I have to ask that because Microsoft conveniently forgot to document
this scenario in the MSDN docs.


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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp via Cygwin]

On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
>
> On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > Jon Turney via Cygwin wrote:
> >
> > > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > > stick to SEM_FAILCRITICALERRORS by default.
> > > >
> > > > The question is this: Why does, apparently, everybody expect Cygwin to
> > > > do the "right thing", with different definitions of "right", when in
> > > > fact the executable in question can easily call SetErrorMode by itself?
> > >
> > > Yeah, if cygwin wasn't involved in the process ancestry, how would you
> > > get the behaviour you want?
> >
> > Ah, but that's how I hit this (and started digging further) -
> > precisely because the non-Cygwin program I'm using _has_ called
> > SetErrorMode and its direct calls to the faulty program _are_ doing
> > what's wanted (no popup dialog) but the calls which happen via Cygwin
> > are then torching that preference.
> >
> > Not really suggesting it be done this way (it feels more complicated
> > than just reverting the change), but in some ways perhaps Cygwin
> > should be using GetErrorMode on startup and instead of not inheriting
> > it, ensuring that it sets whatever it received? i.e. just before the
> > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > error mode (for that thread only) to the value read at startup, calls
> > CreateProcess and then sets the error mode back.
>
> This sounds like a good ide, but...
>
> Is it actually a safe bet that the error mode set by SetThreadErrorMode
> is then propagated as process error mode to the child process?
>
> I have to ask that because Microsoft conveniently forgot to document
> this scenario in the MSDN docs.

:o) Never knowingly clear, are they! It would seem to be the intent of
SetThreadErrorMode that it would behave that way but who knows.

Happy to set up a quick experiment to check that it does work (i.e.
the invoked process has GetErrorMode set as expected) and that there's
no possible race between two threads in the calling process with
differing values (i.e. that having SEM_FAILCRITICALERRORS in one
thread and not in another behaves as expected. If it does appear to
work consistently, would you be willing to go down this route? Happy
to do the patch, although it'd be very helpful to have a couple of
pointers: I'm guessing the value would want to be captured just before
the one place where SetErrorMode is already called, but in which
structure should it then be stashed away to be reused in spawn?


David

-- 
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: emacs 29.2-2 (TEST)

[Jim Reisert AD1C via Cygwin]

On Fri, Feb 2, 2024 at 10:53 AM Ken Brown  wrote:


> On 2/2/2024 9:40 AM, Jim Reisert AD1C wrote:
> > The first time I opened this version with a .CSV file:
> >
> >   ■  Warning (comp): libgccjit.so: error: error invoking gcc driver
> >   ■  Warning (comp): /usr/share/emacs/29.2/lisp/ezimage.el.gz: Error:
> > Internal native compiler error failed to compile
> [...]
> >   ■  Warning (comp):
> > /usr/share/emacs/29.2/lisp/emacs-lisp/cl-seq.el.gz: Error: Internal
> > native compiler error failed to compile
>
> I can't reproduce this.  Did you by any chance forget to install the
> test release of emacs-common?

I don't think so, but I can't access that computer right now.

I did the same update on my laptop and it all seems OK, so I'll have
to check when I get home.

-- 
Jim Reisert AD1C, , https://ad1c.us

-- 
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 18:22, Corinna Vinschen via Cygwin wrote:
> On Feb  2 14:56, David Allsopp via Cygwin wrote:
> > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > > > Not really suggesting it be done this way (it feels more complicated
> > > > than just reverting the change), but in some ways perhaps Cygwin
> > > > should be using GetErrorMode on startup and instead of not inheriting
> > > > it, ensuring that it sets whatever it received? i.e. just before the
> > > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > > > error mode (for that thread only) to the value read at startup, calls
> > > > CreateProcess and then sets the error mode back.
> > >
> > > This sounds like a good ide, but...
> > >
> > > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > > is then propagated as process error mode to the child process?
> > >
> > > I have to ask that because Microsoft conveniently forgot to document
> > > this scenario in the MSDN docs.
> > 
> > :o) Never knowingly clear, are they! It would seem to be the intent of
> > SetThreadErrorMode that it would behave that way but who knows.
> > 
> > Happy to set up a quick experiment to check that it does work (i.e.
> > the invoked process has GetErrorMode set as expected) and that there's
> > no possible race between two threads in the calling process with
> > differing values (i.e. that having SEM_FAILCRITICALERRORS in one
> > thread and not in another behaves as expected. If it does appear to
> > work consistently, would you be willing to go down this route? Happy
> > to do the patch, although it'd be very helpful to have a couple of
> > pointers: I'm guessing the value would want to be captured just before
> > the one place where SetErrorMode is already called, but in which
> > structure should it then be stashed away to be reused in spawn?
> 
> Wanna try this?  It ignores the case of starting a process
> under another user account for now, but that can be added easily
> if this proves to work as expected.

During dinner it occured to me that I forgot to remove setting the
default error mode via CreateProcess.  So this patch would have
to be applied as well:

diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..2e0f0fcf2146 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -401,13 +401,6 @@ child_info_spawn::worker (const char *prog_arg, const char 
*const *argv,
 
   c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT;
 
-  /* Add CREATE_DEFAULT_ERROR_MODE flag for non-Cygwin processes so they
-get the default error mode instead of inheriting the mode Cygwin
-uses.  This allows things like Windows Error Reporting/JIT debugging
-to work with processes launched from a Cygwin shell. */
-  if (!real_path.iscygexec ())
-   c_flags |= CREATE_DEFAULT_ERROR_MODE;
-
   /* We're adding the CREATE_BREAKAWAY_FROM_JOB flag here to workaround
 issues with the "Program Compatibility Assistant (PCA) Service".
 For some reason, when starting long running sessions from mintty(*),

However, it occured to me that this won't work at all.

Consider fork/exec.  In Windows terms, the forked process is a child
process started with CreateProcess.  The forked child is a Cygwin
process, so at DLL init time, it sets

  orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
   | SEM_NOGPFAULTERRORBOX);

However, given the parent is always a Cygwin parent, orig_proc_error_mode
will always be SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX.

The following exec starting a non-Cygwin process will set the thread
error mode to the above value.  So any non-Cygwin process started from
your typical Cygwin process like bash, will always have the error mode
set to the same mode as any Cygwin application.

Ultimately this means, the effect is the same as if we had just reverted
commit 21ec498d7f912 ("cygwin: use CREATE_DEFAULT_ERROR_MODE in spawn").


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: ipython failing after last python code update.

[Emilio Rojas via Cygwin]

Thanks, it worked.  On the downside, it motivated me to get Windows python
working from the bash cmd line, so I'll likely be doing that.  I already
needed to run my scripts with the Windows python and it is two versions
ahead.

Emilio (eo) Rojas
---





On Fri, Feb 2, 2024 at 2:49 AM marco atzeri  wrote:

> On Fri, Feb 2, 2024 at 11:34 AM Emilio Rojas via Cygwin  wrote:
> >
> > I've attached the cygcheckout.out file.
> >
> > python3.9.18 seems to work fine, but when I run ipython8.18.1 it hangs
> > after tying any command.
> >
>
> Hi Emilio,
> you are in the right place.
>
> Others have reported similar problems on other python packages
>
> https://cygwin.com/pipermail/cygwin/2024-January/255273.html
> https://cygwin.com/pipermail/cygwin/2024-January/255267.html
>
> and going back to 3.9,16-1 solved their issue.
>
> Can you confirm that using previous version python 3.9.16-1 you have
> no problem ?
>
> The easy way to replace python39 version 3.9.18-1 with version
> 3.9.16-1 is to select "Sync" at the Package selection window
>
> 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

[no subject]

[Lester Ingber via Cygwin]

Brian:

Yes, I am using the latest package versions.

I am not running letsencrypt on her machine (I am on mine).

When I perform:
08:41:18 @LouiseLG:/etc/pki/ca-trust:% ls -dl /etc/pki/ca-trust/**/
drwxr-xr-x 1 lingber None 0 Feb  1 08:28 /etc/pki/ca-trust/extracted/
drwxr-xr-x 1 lingber None 0 Feb  1 08:28 /etc/pki/ca-trust/source/

When I perform:
ls -dglo /etc/pki/ca-trust/**/
I get the same results.

I added letsencrypt as you suggested.

I now see:
Package: _/ca-certificates-letsencrypt
ca-certificates-letsencrypt.sh exit code 1
Package: _/Unknown package
ca-certificates.sh exit code 1

Lester


On 2024-02-01 08:40, Lester Ingber via Cygwin wrote:
> Yes, a Reinstall is the first thing I tried.
> I just tried that again after installing 3.5.0-1, with the same negative
> result.

Presumably you are installing the latest package versions?

There used to be a problem where the programs made the directories read only so
updates failed.

Check /var/log/setup.log.full for errors perhaps from
ca-certificates/-letsencrypt or p11-kit.

Try checking permissions by running `ls -dl /etc/pki/ca-trust/**/`:

$ ls -dglo /etc/pki/ca-trust/**/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/
drwxr-xr-x 1 0 Jan  8 07:31 /etc/pki/ca-trust/extracted/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/edk2/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/java/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/openssl/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/pem/
dr-xr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/pem/directory-hash/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/source/
drwxr-xr-x 1 0 Sep  6  2022 /etc/pki/ca-trust/source/anchors/
drwxr-xr-x 1 0 Sep  6  2022 /etc/pki/ca-trust/source/blacklist/

note only directory-hash is read only [used -go to omit ids and reduce width].

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

-- 
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: ca-certificates.sh cannot install?

[Lester Ingber via Cygwin]

I added letsencrypt as you suggested.


I now see:

Package: _/ca-certificates-letsencrypt
ca-certificates-letsencrypt.sh exit code 1
Package: _/Unknown package
ca-certificates.sh exit code 1

-- 
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 14:56, David Allsopp via Cygwin wrote:
> On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > > Not really suggesting it be done this way (it feels more complicated
> > > than just reverting the change), but in some ways perhaps Cygwin
> > > should be using GetErrorMode on startup and instead of not inheriting
> > > it, ensuring that it sets whatever it received? i.e. just before the
> > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > > error mode (for that thread only) to the value read at startup, calls
> > > CreateProcess and then sets the error mode back.
> >
> > This sounds like a good ide, but...
> >
> > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > is then propagated as process error mode to the child process?
> >
> > I have to ask that because Microsoft conveniently forgot to document
> > this scenario in the MSDN docs.
> 
> :o) Never knowingly clear, are they! It would seem to be the intent of
> SetThreadErrorMode that it would behave that way but who knows.
> 
> Happy to set up a quick experiment to check that it does work (i.e.
> the invoked process has GetErrorMode set as expected) and that there's
> no possible race between two threads in the calling process with
> differing values (i.e. that having SEM_FAILCRITICALERRORS in one
> thread and not in another behaves as expected. If it does appear to
> work consistently, would you be willing to go down this route? Happy
> to do the patch, although it'd be very helpful to have a couple of
> pointers: I'm guessing the value would want to be captured just before
> the one place where SetErrorMode is already called, but in which
> structure should it then be stashed away to be reused in spawn?

Wanna try this?  It ignores the case of starting a process
under another user account for now, but that can be added easily
if this proves to work as expected.

diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index a40129c22232..f1017e69b6b2 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -718,7 +718,8 @@ dll_crt0_0 ()
   init_windows_system_directory ();
   initial_env ();
 
-  SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
+  orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
+  | SEM_NOGPFAULTERRORBOX);
 
   lock_process::init ();
   user_data->impure_ptr = _impure_ptr;
diff --git a/winsup/cygwin/globals.cc b/winsup/cygwin/globals.cc
index 885ada85e7b8..d2861ba98b42 100644
--- a/winsup/cygwin/globals.cc
+++ b/winsup/cygwin/globals.cc
@@ -28,6 +28,7 @@ PWCHAR windows_directory = windows_directory_buf + 4;
 UINT windows_directory_length;
 UNICODE_STRING windows_directory_path;
 WCHAR global_progname[NT_MAX_PATH];
+UINT orig_proc_error_mode;
 
 /* program exit the program */
 
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..df83f25d13c6 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -648,6 +648,10 @@ child_info_spawn::worker (const char *prog_arg, const char 
*const *argv,
  && !::cygheap->user.groups.issetgroups ()
  && !::cygheap->user.setuid_to_restricted))
{
+ UINT orig_thread_error_mode = SEM_FAILCRITICALERRORS
+   | SEM_NOGPFAULTERRORBOX;
+ if (!iscygwin ())
+   SetThreadErrorMode (orig_proc_error_mode, _thread_error_mode);
  rc = CreateProcessW (runpath, /* image name w/ full path */
   cmd.wcs (wcmd),  /* what was passed to exec */
   sa,  /* process security attrs */
@@ -658,6 +662,8 @@ child_info_spawn::worker (const char *prog_arg, const char 
*const *argv,
   NULL,
   ,
   );
+ if (!iscygwin ())
+   SetThreadErrorMode (orig_thread_error_mode, NULL);
}
   else
{

-- 
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: ca-certificates{,-letsencrypt}

[Brian Inglis via Cygwin]

Hi Lester,

You should see those other directories on both machines.
I suggest re-installing those packages using latest setup-x86_64 with admin 
rights;
ensure in Task Manager that nothing is running from Cygwin bin paths before 
starting until postinstall scripts have completed;

after check for errors in /var/log/setup.log.full.

On 2024-02-02 09:57, Lester Ingber via Cygwin wrote:

Yes, I am using the latest package versions.
I am not running letsencrypt on her machine (I am on mine).
When I perform:
08:41:18 @LouiseLG:/etc/pki/ca-trust:% ls -dl /etc/pki/ca-trust/**/
drwxr-xr-x 1 lingber None 0 Feb  1 08:28 /etc/pki/ca-trust/extracted/
drwxr-xr-x 1 lingber None 0 Feb  1 08:28 /etc/pki/ca-trust/source/
When I perform:
ls -dglo /etc/pki/ca-trust/**/
I get the same results.
I added letsencrypt as you suggested.
I now see:
Package: _/ca-certificates-letsencrypt
ca-certificates-letsencrypt.sh exit code 1
Package: _/Unknown package
ca-certificates.sh exit code 1



On 2024-02-01 08:40, Lester Ingber via Cygwin wrote:

Yes, a Reinstall is the first thing I tried.
I just tried that again after installing 3.5.0-1, with the same negative
result.


Presumably you are installing the latest package versions?

There used to be a problem where the programs made the directories read only so
updates failed.

Check /var/log/setup.log.full for errors perhaps from
ca-certificates/-letsencrypt or p11-kit.

Try checking permissions by running `ls -dl /etc/pki/ca-trust/**/`:

$ ls -dglo /etc/pki/ca-trust/**/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/
drwxr-xr-x 1 0 Jan  8 07:31 /etc/pki/ca-trust/extracted/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/edk2/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/java/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/openssl/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/pem/
dr-xr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/extracted/pem/directory-hash/
drwxr-xr-x 1 0 Jan  8 07:36 /etc/pki/ca-trust/source/
drwxr-xr-x 1 0 Sep  6  2022 /etc/pki/ca-trust/source/anchors/
drwxr-xr-x 1 0 Sep  6  2022 /etc/pki/ca-trust/source/blacklist/

note only directory-hash is read only [used -go to omit ids and reduce width].


--
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: emacs 29.2-2 (TEST)

[Ken Brown via Cygwin]

[Redirecting to the cygwin list.]

On 2/2/2024 9:40 AM, Jim Reisert AD1C wrote:

The first time I opened this version with a .CSV file:

  ■  Warning (comp): libgccjit.so: error: error invoking gcc driver
  ■  Warning (comp): /usr/share/emacs/29.2/lisp/ezimage.el.gz: Error:
Internal native compiler error failed to compile

[...]

  ■  Warning (comp):
/usr/share/emacs/29.2/lisp/emacs-lisp/cl-seq.el.gz: Error: Internal
native compiler error failed to compile


I can't reproduce this.  Did you by any chance forget to install the 
test release of emacs-common?


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

openh264 2.4.1-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libopenh264-headers-2.4.1-1
* libopenh264-2.4.1-1

OpenH264 is a codec library which supports H.264 encoding and decoding. It is 
suitable for use in real time applications such as WebRTC. The binary library 
(runtime) itself will be downloaded from http://ciscobinary.openh264.org/
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

emacs 29.2-2 (TEST)

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution as 
test releases.


* emacs-29.2-2
* emacs-common-29.2-2
* emacs-basic-29.2-2
* emacs-w32-29.2-2
* emacs-gtk-29.2-2
* emacs-lucid-29.2-2

Emacs is a powerful, customizable, self-documenting, modeless text 
editor.  Emacs contains special code editing features, a scripting 
language (elisp), and the capability to read mail, news, and more 
without leaving the editor.


This is the same as emacs-29.2-1, but it is built with the native 
compilation feature, which we explain briefly:


Many of the editing commands used in Emacs are defined in elisp 
libraries (*.el files).  To make Emacs run faster, these libraries are 
usually compiled to architecture-independent *.elc files, containing 
"byte-code" representations of the functions in the original files. 
These byte-code functions are interpreted by the Emacs "byte-code 
interpreter" when they are called.


Native compilation takes this one step further by using gcc to compile 
the elisp libraries to native shared libraries (like DLLs, but with an 
extension .eln instead of .dll).  This results in a substantial speed-up 
of Emacs.


Some of the .eln files are created at build time.  These are installed 
in a subdirectory of /usr/lib/emacs//native-lisp.  Others are 
created as needed and are stored by default in a subdirectory of 
~/.emacs.d/eln-cache.


The first few times you run Emacs, it might seem slow to start.  This is 
because it is compiling the elisp libraries that are needed for your 
init file (usually .emacs).  For the same reason, you might see 
occasional pauses the first time you use a command.  But otherwise you 
should see a noticeable speed-up of Emacs.


The .eln files have been built with ASLR[1] enabled.  The hope is that 
this eliminates the fork failures (and the need to rebase) that were 
present in some of the previous releases with native compilation.


If you experience a fork failure in spite of this, please make a bug 
report to the mailing list.  I'd also like to get feedback from people 
who try the test release for a month or so and don't have any problems.


Ken

[1] 
https://www.mandiant.com/resources/blog/six-facts-about-address-space-layout-randomization-on-windows

--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

[PATCH] Cygwin: console: Avoid slipping past disable_master_thread check.

[Takashi Yano]

If disable_master_thread flag is set between the code checking that
flag not be set and the code acquiring input_mutex, input record is
processed once after setting disable_master_thread flag. This patch
prevents that.

Fixes: d4aacd50e6cf ("Cygwin: console: Add missing input_mutex guard.")
Signed-off-by: Takashi Yano 
---
 winsup/cygwin/fhandler/console.cc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/fhandler/console.cc 
b/winsup/cygwin/fhandler/console.cc
index 6a42b4949..1c8d383cd 100644
--- a/winsup/cygwin/fhandler/console.cc
+++ b/winsup/cygwin/fhandler/console.cc
@@ -420,6 +420,12 @@ fhandler_console::cons_master_thread (handle_set_t *p, tty 
*ttyp)
}
 
   WaitForSingleObject (p->input_mutex, mutex_timeout);
+  /* Ensure accessing input recored is not disabled. */
+  if (con.disable_master_thread)
+   {
+ ReleaseMutex (p->input_mutex);
+ continue;
+   }
   total_read = 0;
   switch (cygwait (p->input_handle, (DWORD) 0))
{
@@ -4545,8 +4551,6 @@ fhandler_console::set_disable_master_thread (bool x, 
fhandler_console *cons)
return;
 }
   const _minor_t unit = cons->get_minor ();
-  if (con.disable_master_thread == x)
-return;
   cons->acquire_input_mutex (mutex_timeout);
   con.disable_master_thread = x;
   cons->release_input_mutex ();
-- 
2.43.0

[PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS

[Christian Franke via Cygwin-apps]

_FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc 
13.2.1 test release.


Silently falls back to level 2 if level 3 is unsupported (older headers 
or gcc) or to level 0 if unsupported at all (C++, clang).


--
Regards,
Christian

From 1a32375682d0e5ff6b80a47de70d3d9cfe0f0780 Mon Sep 17 00:00:00 2001
From: Christian Franke 
Date: Fri, 2 Feb 2024 17:00:18 +0100
Subject: [PATCH] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS

This enables buffer overflow checks if the buffer size is non-const
but known during runtime and GCC 12.0 or later is used.
---
 lib/compilers.cygpart | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/compilers.cygpart b/lib/compilers.cygpart
index 35e6fe28..52df5304 100644
--- a/lib/compilers.cygpart
+++ b/lib/compilers.cygpart
@@ -34,9 +34,9 @@ declare -x CC="gcc";
 #  Flags passed to CC when compiling C code.  Individual packages may append
 #  or override this value if they will not build correctly without it.
 #  DEFAULT VALUE
-#  -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-fstack-protector-strong --param=ssp-buffer-size=4
+#  -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=3 
-fstack-protector-strong --param=ssp-buffer-size=4
 #
-declare -x CFLAGS="-ggdb -O2 -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4";
+declare -x CFLAGS="-ggdb -O2 -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=3 -fstack-protector-strong --param=ssp-buffer-size=4";
 
 #v* Compiling/CPPFLAGS
 #  DESCRIPTION
-- 
2.43.0

Updated: dash 0.5.12-5

[Cygwin dash Co-Maintainer]

The following package has been upgraded in the Cygwin distribution:

* dash  0.5.12-5

DASH is a POSIX-compliant implementation of /bin/sh that aims to be
as small as possible. It does this without sacrificing speed where
possible. In fact, it is significantly faster than bash (the GNU
Bourne-Again SHell) for most tasks.

This package is being upgraded to current as an earlier release broke
existing function that may be relied on by some scripts, and the current
stable Cygwin release now supports locale dependent named character
class, equivalence class, and collating symbol filename patterns
required by this package release.

Add /bin/dash-VER-R link, plus version and date stamp on man page, as no
shell version info or query is available.

This release has been rebuilt re-enabling libc fnmatch and glob as
Cygwin/winsup now supports locale dependent named character class,
equivalence class, and collating symbol filename patterns like glibc,
and has been available for testing for some time.

Thanks to Andrey Repin for testing and bringing this to our attention,
Harald van Dijk on the dash list for pointing out the commit
responsible, and Corinna Vinschen for adding support for locale
dependent named character, equivalence class, and collating symbol
patterns to the Cygwin libc fnmatch and glob functions.

For more information see the project home page:

http://gondor.apana.org.au/~herbert/dash/

For changes since the previous release, see below;
for complete details see:

https://git.kernel.org/pub/scm/utils/dash/dash.git/log/?h=v0.5.12=1


2022-12-11  0.5.12

error:
Remove USE_NORETURN ifdef

eval:
Always set exitstatus in evaltree
Check eflag after redirection error
Check nflag in evaltree instead of cmdloop
Do not cache value of eflag in evaltree
Prevent recursive PS4 expansion
Test evalskip before flipping status for NNOT

expand:
Add ifsfree to expand to fix a logic error that causes a buffer 
over-read
Always quote caret when using fnmatch
Make glob(3) interruptible by SIGINT

input:
Clear unget on RESET
Remove special case for unget EOF

jobs:
Always reset SIGINT/SIGQUIT handlers
Block signals during tcsetpgrp
Fix waitcmd busy loop
Only block in waitcmd on first run

man:
fix formatting

parser:
Add VSBIT to ensure subtype is never zero
Fix VSLENGTH parsing with trailing garbage
Get rid of PEOA

redir:
Retry open64 on EINTR

shell:
Call CHECK_DECL on stat64
Disable glob again as it strips trailing slashes
Enable fnmatch/glob by default
Fail if building --with-libedit and can't find libedit
Group readdir64/dirent64 with open64

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.