X-Recipient: archive-cygwin@delorie.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:subject:to:references:from:reply-to:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=J/MJGjNiXeby0i73
	QE71lF9Ml0kUSEYn2YkdS+Y0ibdLslLea6yvPMbgq0XtrC/wzRaVLufLpxULcj7Y
	b+Oyc01QhJFIjmBYSJthx/ldP7yQgDDPz1NjNVMeHRQKEACYJ0ybawokXVrwEhO3
	IZ4CkhQyTCO+Gu/bfSR8pSWGB30=
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:subject:to:references:from:reply-to:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=Z6MkFPGtbvmQWVdNreaD1y
	9QtPg=; b=p3z5HI6NDH3anLx/3Wtq5tto6b45frRrNOIYh1iaAQf8UjZAeoeMSi
	VUtv9+VCiRoeWw8Oj0PQjoSvBMclL/zy0sCBq8Esh6O5stHLE0tQH27TDHylPsFY
	OBaLE3baXuWPWlHI5MZri0eiWir3Adk+ktGouqm6vMcdNQQwlFG3g=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=2.9 required=5.0 tests=BAYES_50,KAM_COUK,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Sam, H*F:U*cygwin, H*r:sk:smtp-ou, ascii
X-HELO: smtp-out-2.tiscali.co.uk
Subject: Re: cygpath
To: cygwin@cygwin.com
References: <91DCAC3CB99C724EB365BB64677FBE7B139A86@MX204CL04.corp.emc.com> <151946397.20170210223617@yandex.ru> <91DCAC3CB99C724EB365BB64677FBE7B139AF9@MX204CL04.corp.emc.com> <e84da808-cba0-589d-d1ec-58f64d8eb351@cs.umass.edu>
From: Sam Edge <cygwin@dwalin.fsnet.co.uk>
Reply-To: cygwin@cygwin.com
Message-ID: <e69be31d-8d6c-b22a-d634-492b656ca772@dwalin.fsnet.co.uk>
Date: Fri, 10 Feb 2017 23:50:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <e84da808-cba0-589d-d1ec-58f64d8eb351@cs.umass.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfGs+3LOuAAZpKJVniH8INIDMHw+pFcRgjh9s+JOtvobjI7KVuqYztHQkxPd/m1PyxzE4N7NkNU9/8+mlpFAreiy6Sp1B4kVait3zFqs+fCZxR8hexu5A MI3GyFcp8ZUPpbs4Mji1XhvYXeCl6IVFRzJqYLwEtvwGIrVU7S2WxqCdps3LY9bFmhtbgkWKCQAFwQ==
X-IsSubscribed: yes

On 10/02/2017 23:17, Eliot Moss wrote:
> On 2/10/2017 3:03 PM, Gluszczak, Glenn wrote:
>> * is a legal character for ls but perhaps not cygpath?  I don't know.
>> No files or directories are using * in the name.
>>
>> Not sure about incorrect terminal settings as I never touched any.
>> It shows up in mintty and ssh equally. The characters that appear vary.
>>
>> Some non-existent paths do *not* produce the gibberish.
>>
>> %%%cygpath -w /aaa/bbb/*
>> C:\cygwin\aaa\bbb\
>
> Yes, but I found something interesting when I did this:
>
> echo "$(cygpath -w /usr/non-existent/*)" > mytemp
>
> od -c mytemp
>
> revealed that there is a three-byte sequence after the
> output of
>
> C:\cygwin\usr\non-existent\
>
> and before the newline added by echo.  I guess it's
> some representation of * that does not show up on the
> terminal, but it did strike me as a little strange ...
>
> Regards - EM
>
> -- 
> 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
>
>
Sorry, did anyone actually read Andrey's post?

(Hint: Read
https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars
again.)

The three byte sequence is the UTF-8 representation of U+F02A i.e. ASCII
for '*' but in the private use area of Unicode.

This is how the Cygwin DLL stores ASCII characters in pathnames that are
forbidden in Windows but that are valid in POSIX. The directory entry
write functions convert them to private area and the read functions
convert them back to Unicode.

The cygpath utility therefore does exactly the same on the assumption
that the result is going to be passed to Windows programs that are going
to manipulate the directory entry in some way - open the file for example.

That they display incorrectly is an inevitable side effect of this
work-around.

Generally, all you need to do is accept the Copenhagen interpretation in
your scripts and just calculate. ;-)

The only thing you need to be careful of is that if you really mean to
pass the glob to your Windows app, you leave it out of the string passed
to cygpath e.g.

cygstart some-exe "$(cygpath -w "some-posix-path/")"\*

instead of

cygstart some-exe "$(cygpath -w "some-posix-path/*")"


-- 
Sam Edge


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

