Ok, We're back to asking for a plugin with a clearly defined interface for
env. var and path translation; despite LRNs reasonable objections I think
it might be the only acceptable solution?
.. that way we can continue to speculate (as MSYS always has) about what's
a path and what isn't and also use the cygwin.dll unmodified.
Otherwise we're at an impasse.
On Wed, Jun 12, 2013 at 3:00 PM, Corinna Vinschen <[email protected]>wrote:
> 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
>
------------------------------------------------------------------------------
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
