DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=meK+YV7qwqxQq0unlpjMCNxT7TE/DjY1VgyijWKhBSO
	sQPAawQ3ah2/HPSolEnl++/A6L9tbdlmsNrwb3bRMnZJfMoB5VpRN4BL9BRxwHOg
	C9fwTIrDF3D5698xBUCB8vAmCYpRStK/FFmeA37ft7oLTq9fAnzBjMI0pr5cuanE
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <51C0B08E.8080900@etr-usa.com>
Date: Tue, 18 Jun 2013 13:10:06 -0600
From: Warren Young <warren AT etr-usa DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Cygwin-L <cygwin AT cygwin DOT com>
Subject: Re: Adding MSYS functionality to Cygwin
References: <CABEPuQJDLjtbcLig1isTUJgb6RBCD8LNShbm9mTPcb9WM5S5fw AT mail DOT gmail DOT com>
In-Reply-To: <CABEPuQJDLjtbcLig1isTUJgb6RBCD8LNShbm9mTPcb9WM5S5fw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Note-from-DJ: This may be spam

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.

> 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.

> 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).

> 4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.

Who needs this, and why?

> 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.

> 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.)

Example:

     $ ln -s dir1 dir2

Cygwin decides it can't make the symlink, so it spends a lot of I/O and 
disk space cloning the tree.  Bad enough.  But then:

      $ vi dir2/somefile.txt
      (make edits, :wq)

Now dir2/somefile.txt is not the same as dir1/somefile.txt.

This is going to break something, I'm sure of it.

--
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