From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31146 invoked by alias); 18 Jun 2013 19:31:04 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 31136 invoked by uid 89); 18 Jun 2013 19:31:04 -0000 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 Received: from mho-02-ewr.mailhop.org (HELO mho-02-ewr.mailhop.org) (204.13.248.72) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 18 Jun 2013 19:31:03 +0000 Received: from pool-108-49-156-142.bstnma.fios.verizon.net ([108.49.156.142] helo=cgf.cx) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Up1cL-0009oV-Uq for cygwin@cygwin.com; Tue, 18 Jun 2013 19:31:01 +0000 Received: from localhost (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 0A23160127 for ; Tue, 18 Jun 2013 15:31:01 -0400 (EDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Report-Abuse-To: abuse@dyndns.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 21:22:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: Adding MSYS functionality to Cygwin Message-ID: <20130618193101.GB4868@ednor.casa.cgf.cx> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <51C0B08E.8080900@etr-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C0B08E.8080900@etr-usa.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-06/txt/msg00461.txt.bz2 [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