delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2010/09/08/11:59:13

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,TW_CG,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
X-ASG-Debug-ID: 1283961501-589f5c6a0002-w5GHUG
X-Barracuda-Envelope-From: daniel AT fgm DOT com
X-ASG-Whitelist: Client
Message-ID: <4C87B2A3.1050702@fgm.com>
Date: Wed, 8 Sep 2010 11:58:27 -0400
From: Daniel Barclay <daniel AT fgm DOT com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6
MIME-Version: 1.0
To: <cygwin AT cygwin DOT com>
Subject: Re: Windows-style pathname does not work as command - why?
References: <4C7FE2C2 DOT 8060104 AT fgm DOT com> <4C7FE938 DOT 6060806 AT redhat DOT com> <20100902211830 DOT GC527 AT ednor DOT casa DOT cgf DOT cx>
X-ASG-Orig-Subj: Re: Windows-style pathname does not work as command - why?
In-Reply-To: <20100902211830.GC527@ednor.casa.cgf.cx>
X-Barracuda-Connect: UNKNOWN[216.2.55.102]
X-Barracuda-Start-Time: 1283961517
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.fgm.com:8000/cgi-mod/mark.cgi
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

Christopher Faylor wrote:
> On Thu, Sep 02, 2010 at 12:13:12PM -0600, Eric Blake wrote:
>> On 09/02/2010 11:45 AM, Daniel Barclay wrote:
>>> I don't quite understand this behavior:
>>>
>>> $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe
>>> C:\tools\emacs-23.2\bin\runemacs.exe
>>> $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe
>>> bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found
>>>
>>> In particular, why is it that bash does not understand that Windows
>>> pathname when it is used as a command argument, even though bash and
>>> Cygwin clearly understand it when it is used as a command argument?
>>>
>>>
>>> Is that behavior a bug (e.g., does bash try to judge whether the command
>>> is an absolute vs. relative pathname without either first converting to
>>> a Unix-style pathname or otherwise recognizing Windows-style pathname)?
>>
>> You're not the first to notice this, but it's also not the highest
>> priority on my list to look into, because we already recommend using
>> POSIX style paths in the first place.
>>
>>> Or is it some known irregularity (resulting from trying to handle both
>>> Windows- and Unix-style pathnames) that couldn't be resolved?
>>
>> Oh, I'm sure that bash could be patched to be smarter about DOS-style
>> pathnames.  But no one has been bothered by it enough to write a patch yet.
>
> And, trying hard to make MS-DOS stuff work is sorta counter to the
> whole reason for Cygwin.

Isn't the whole reason for Cygwin actually to enable doing Unixy things
in Windows (that is, providing Windows/Unix interoperablity?

Also, to clarify:  I didn't mean DOS-specific pathnames, as opposed to
general Windows pathname (e.g., meaning 8.3-style vs. VFAT long names).
I just meant DOS-/Windows-style pathnames (as opposed to Unix-style
pathnames).


Daniel







Daniel













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


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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019