On Jun 12 15:50, Alexpux wrote: > среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал: > > On Jun 11 21:10, Алексей Павлов wrote: > > > MSYS includes the following changes to Cygwin to support using native > > > Win32 > > > programs: > > > 1. Automatic path mangling of command line arguments and environment > > > variables to Win32 form on the fly for Win32 applications inside bash.exe > > > > > > > > > That's a bash change which does not affect the underlying Cygwin/MSYS DLL. > > > This is changes in Cygwin dll not in bash. See changes in path.cc, spawn.cc > and new files msys.cc and is msys.cc
You wrote it's a bash change. As a bash change I can understand it, as a Cygwin change not so much. This is pure speculating on the DLL side again. You simply don't know exactly if something is a path and in what form the argument is used by the called application. If in doubt, use cygpath. > > > 2. Ability to change OSNAME with an environment variable (MSYSTEM) to > > > change it between MSYS and MINGW32 (so people can add to or fix MSYS > > > programs should they need to). > > > > > > > > > Ditto. > Cygwin dll function uname changes Sigh. > > > 3. Conversion of output of native Win32 application output from Windows > > > line endings to Posix line endings - removing trailing '\r' symbol - in > > > bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as expected. > > > > > > > > > Ditto. > Yes it is bash changes and they also can be integrated in Cygwin bash I think > man dos2unix > > > 4. Replaced Cygwin symlinks with copying (we can investigate an option for > > > mklink symlinks on Vista and above but this is a topic for discussion - > > > MSYS compliant software tend to work around most ln-as-cp issues when > > > possible anyway). > > > > > > > > > I said my share about what I think of copying files when the application > > expects to get a symlink. It's wrong. It's dangerous. You still have > > the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or > > CYGWIN=winsymlinks:nativestrict options available when using Cygwin > > unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html) > > > > > > Yes it dangerous but native symlinks work need elevated shell and OS Vista+ Again, if you need a copy, use cp, not ln -s. It's plainly a bug in the scripts or tools you're using, if they use ln -s (or symlink(2)) when called in a Mingw environment. Neither of them must rely on symlinks. > > I'm not negative. I'm just defending the integrity of the Cygwin DLL. > > > > Again, I'm perfectly happy if you provide an MSYS2 distro containing > > special tools, like a tweaked bash and an entire, Mingw-centric > > toolchain arrangement, as long as you keep the underlying Cygwin DLL > > intact as provided upstream. Also, don't change the name of the DLL and > > the target name of the toolchain ({i686/x86_64}-pc-cygwin). > > > > Everyone would have an advantage of this: > > > > - There would be only one source of the underlying POSIX-providing DLL. > > Central repository, only one source to care about, no merging and > > tweaking hassle. > > > > - The DLL name stays intact, thus every tool built in and for the MSYS2 > > environment would run in a Cygwin distro environment as well. > > - The toolchain name stays intact. You can just grab the latest gcc and > > binutils sources and build them for the upstream supported > > ${arch}-pc-cygwin target and it would create files running in both > > environments. > > > > - While the normal Mingw/MSYS2 user would not have to look into the > > Cygwin distro since the MSYS2 distro provides what he or she needs, > > the more demanding user of MSYS2 would have free access to all tools > > provided by the Cygwin distro with thousands of tools and applications, > > not to mention a fully function X server with X clients. > > > > That's all I'm trying to say. I don't see a good reason to change the > > Cygwin DLL. Use it as is and build your Mingw-targeting environment > > around it. I'm here to help if something doesn't work out as you need > > it. Maybe we find another, working solution, without having to fork > > Cygwin. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
