X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=tUILF7ODgbNQa4GGkF4LfsIBAsL5xX0MsfVFYcV5g/WwRaHLy442y
	nAbD5HFRTJIiLgCo6AzVey3bNlgKPKE9VKG/S9cCppPDKMd7IqAvcqUZ8XKTBE1S
	sLiB82WYqScA9CgHbyZ8OwWi4KPFwmOAJHHW3Sz7GD+kkM8N90MlW4=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=DVvje+/8ULC57ECT3q+Y8dmkKOw=; b=ccGK4b0EVJ2+FupqlK17k/i47NCz
	//QKnsm3qz5ghED5YKRV9wNxZwsYNUtp48dH/qPxaWLiqTCBqKuS6GI956D8SA0B
	cuGVJOpxI2Ztl4/qAVyiGNuo/4nipq33KYtFhbtUtko+Fu+ZZJLwQvv/LAqB4nlL
	ZbdCAP+AenmLlXc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1
X-Mail-Handler:	Dyn Standard SMTP by Dyn
X-Report-Abuse-To:	abuse AT dyndns DOT com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User:	U2FsdGVkX18RrGITPst8cD6n+BqEHqdN
Date:	Tue, 18 Jun 2013 15:31:01 -0400
From:	Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Adding MSYS functionality to Cygwin
Message-ID:	<20130618193101.GB4868@ednor.casa.cgf.cx>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<CABEPuQJDLjtbcLig1isTUJgb6RBCD8LNShbm9mTPcb9WM5S5fw AT mail DOT gmail DOT com> <51C0B08E DOT 8080900 AT etr-usa DOT com>
MIME-Version:	1.0
In-Reply-To:	<51C0B08E.8080900@etr-usa.com>
User-Agent:	Mutt/1.5.20 (2009-06-14)

[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

- Raw text -