On Fri, 2 Feb 2024, Corinna Vinschen wrote: > On Feb 2 09:43, David Allsopp via Cygwin wrote: > > 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? > > > > 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 different definitions of "right" is the reason the flag/option was re-added in MSYS2. I think the most "right" thing Cygwin could do (if it were to only do one thing, rather than having an option) would be to somehow have native processes inherit the error mode as though Cygwin were not in the mix. The issue with that, as you've seen, is that there are any number of Cygwin processes in the hierarchy. As far as the executable being able to call SetErrorMode itself, that would be OK except for when the error is coming from the loader, before anything from the executable is run (such as for missing DLL or missing export from DLL). I do like the idea of a native Windows program like "nohup" that sets the error mode and then runs a subprocess. Why doesn't Windows come with something like that? ;) -- 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
