Adding MSYS functionality to Cygwin

[Christopher Faylor]

[I'm being a reluctant explicator here]

On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
>On 6/18/2013 12:40, ?????????????? ???????????? wrote:
>>
>> 1. The correct definition of executables belonging to Cygwin DLL.
>
>Can you give an example of what you mean here?
>
>This must be some kind of translation error, since executables never 
>belong to DLLs.  The reverse is sometimes true, but mostly not.

I don't get this one either.  Maybe the OP means that cygwin has to know
when to translate command-line arguments for non-Cygwin executables?

>> 2. Translating paths in arguments and environment variables to Windows
>> form for pure Win32 applications.
>
>I don't see how Cygwin can reliably predict when and whether to do this. 
>  That is why it provides cygpath(1).  You, the user, use that tool when 
>you know you need a translation done.

Yep.  Welcome to MSYS.  I believe that MSYS translates "things that look
like paths" so if you do something like: "foo /blah/blurf" and "foo" is
a Windows program then "/blah/blurf" gets translated into
"c:\whatever\blah\blurf".

>> 3. In MSYS mode Cygwin need to be very portable
>
>It would indeed be nice to have a portable Cygwin.  That is, one that 
>could be run from a copied directory or USB key, without being formally 
>installed.  Such a thing would need to solve the 3PP problem, though, 
>which is Hard (tm).

Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.

>> 4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.
>
>Who needs this, and why?

Maybe it needs to identify itself as "MSYS" for configure scripts?

>> 5. Use shorted mount point options in /etc/fstab - only win32_path and
>> posix_path.
>
>Why do you need this?
>
>Doesn't it conflict with your point #3?  A portable Cygwin would go out 
>of its way to avoid using /etc/fstab.  I would guess that such a Cygwin 
>variant would simply provide an unchangeable default behavior, and you'd 
>have to be happy with it.

Don't get this one either.

>> 6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>> used in all situations. From the other side - Win32 applications
>> doesn't understand Cygwin symlinks. As fallback option we need to
>> create copies of files and directories instead symlinks.
>
>Copy semantics are not an acceptable fallback for ln.  (Or where they 
>are, you can do your own copying.)

All of the above is just an explanation of the way that MSYS currently
operates.  The argument about semantics of ln (which I agree with)
doesn't really matter since "that's how MSYS works".

This is, however, one of the reasons why I'm not comfortable modifying
Cygwin to behave differently.  Having spent the last 15 years telling
people "That isn't the way POSIX works" makes it hard for me to say
"But if that's what you want then just set CYGWIN=WINCOMPAT and you'll
get it" .

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple