This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: MSYS mode (continue)
- From: LRN <lrn1986 at gmail dot com>
- To: cygwin-developers at cygwin dot com
- Date: Fri, 26 Jul 2013 01:07:59 +0400
- Subject: Re: MSYS mode (continue)
- References: <20130704103708 dot GA12995 at calimero dot vinschen dot de> <CABEPuQ+iF265-SQzfLTmsBegG+BVjpLPowxRAH8ioWv1Us_iYg at mail dot gmail dot com> <20130704121617 dot GC12995 at calimero dot vinschen dot de> <20130704163612 dot GA4729 at ednor dot casa dot cgf dot cx> <20130705090704 dot GB4009 at calimero dot vinschen dot de> <20130705164230 dot GA7282 at ednor dot casa dot cgf dot cx> <20130711111744 dot GG15346 at calimero dot vinschen dot de> <51F123EB dot 9000900 at cwilson dot fastmail dot fm> <20130725150209 dot GA15619 at calimero dot vinschen dot de> <51F16C82 dot 7030509 at cwilson dot fastmail dot fm> <20130725205320 dot GA2725 at ednor dot casa dot cgf dot cx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 26.07.2013 00:53, Christopher Faylor wrote:
> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>>> But underlying there's still a normal Cygwin DLL and
>>> most tools could just be copied verbatim since they don't need this
>>> extra functionality.
>>
>> And that's the bit where I disagree. Sure, some scripting tools might
>> not need adjustment, so long as their interpreter was $MSYS-enabled
>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see"
>> dos-style paths, so its interpreter better be able to handle them.
>>
>> But unless you restrict yourself to only passing around relative paths
>> (or god forbid, that old "unity mount" idea), any .exe will need to live
>> in one world or the other. Otherwise, how would paths be interpreted?
>> Using which tools' mount table?
>>
>> Naturally from the command line I can compensate:
>>
>> msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath
>> -d /msys/mount/table/path) )
>>
>> but yee gods that'd be annoying in any automated setting.
>
> I don't know if this helps but the vague plan is to now have two DLLs
> where before you only had one. You'd still be providing "MSYS" binaries
> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
> small dll which relied on cygwin1.dll for all of the heavy lifting.
>
> You'd still have a normal MSYS distribution and it would still, in theory,
> support everything (with the possible exception of very lax security) that
> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll,
> bash, etc.
Out of curiosity: why do you insist on having MSYS functionality in a
separate dll, when it could be just part of cygwin1.dll (disableable and
enableable in the same way other Cygwin features are disabled/enabled -
via CYGWIN envvar)? What advantage would that give, that justifies the
increase in implementation complexity (hooking up the dll, etc)? Was
that justified earlier in this thread and i just neglected to read that
far back?
Also, i'm planning on building experimental cygwin dll that doesn't use
NO_ACL on mounts by default (msys2 always uses NO_ACL on mounts by
default) and see if it works for me. If it does, that'll remove yet
another item from the list of msys vs cygwin differences, at least for me.
- --
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJR8ZOtAAoJEOs4Jb6SI2CwUSgIAJdl3w68YM9QQ+W4/HC4cWnj
7Nup127y2LI31ZaNKsr29XVfk9PaGCDYx/Ueoi5CCaOmZCaRmeAWGnaS6ftXjstf
KM1/ph/dIOx7nT2jHP3eWRp1IJh1DIHUOS0ZuTilgHWZzbpteKwdyq+WOuF1dT0J
c11ue23sYPSJ2QyXGYBuOfCjok+HCGCnfX305DKhWNwriw57xcixU8pU8TaGRDM8
zUlC2VJ3NO7e3Es2JDIq4uqVkh/JFdUZ+2W63W+xyTQyRJgLzA7egnq+8fpoX2HN
qM70cvmv2wD0AhS2tAHYPOPCGlfwoayd+dAJCVyy/cgs1qCnS/3N0yy6xTGkXGg=
=bHcW
-----END PGP SIGNATURE-----