Greetings, Old, Oliver! >> Then do not mix environments.
> That is not my choice, but rather my supervisor's choice. I began > engineering our new CMake-based build system purely with MinGW > toolchains in mind, statically linked ones even since I already know how > well-received it would be if I required people to install a MinGW > environment and had them add it to their PATH. > Then I was told we might have to abandon this new system if we can't > keep using our Cygwin toolchains. Then this is not an issue with Cygwin, or mingw, but rather, with the tools you are using. > I know it is very unwise to attempt this and entirely unproductive. >> Cygwin with automation scripts. > I wish that was good enough, but I'm supposed to make it work with all > the GUI and integrated debugging capabilities the other toolchains have. > It is so very frustrating. > Back to the technical aspects: I just don't see why the current command > line handling is supposed to be good. It is not good or bad. Keep in mind that there are more pieces moving than what you are thinking there are. > I find it to be very surprising as > its entire purpose is interfacing with non-Cygwin software. Why should > the "non-Cygwin" software assume the command line to be parsed according > to Bash's rules? No. It first parsed by CMD itself according to its own rules (CMD /? helps to clarify some o 'em, but I would strongly suggest https://ss64.com/nt/ as a WAY, WAY better source of information), and only when the line is passed down to the cygwin app, the Cygwin DLL reassebles and reparses the line according to POSIX rules. -- With best regards, Andrey Repin Saturday, August 9, 2025 14:24:26 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
