DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=m5aE/DXNHGh/nht7f56QlgKZ88KzFSE681+D6IJGzlN
	oqH329Tx8y61+4sZTEcdcaJtXZgFD/RETMQJJAG1+XD55horVOWyg763AYa1MMjH
	qQtj8Q0e7k+eVkNHEVcXCXK7u9RHi7hZc7vuKqu9QDDd06DcXWilnOekCNCtvVA8
	=
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
MIME-Version: 1.0
In-Reply-To: <151946397.20170210223617@yandex.ru>
References: <91DCAC3CB99C724EB365BB64677FBE7B139A86 AT MX204CL04 DOT corp DOT emc DOT com> <151946397 DOT 20170210223617 AT yandex DOT ru>
From: Michael Enright <mike AT kmcardiff DOT com>
Date: Fri, 10 Feb 2017 12:37:10 -0800
Message-ID: <CAOC2fq8qG6xghRuUdRqR3bX4Ndeio-viox6X2hzS7D=dFfYmXQ@mail.gmail.com>
Subject: Re: cygpath
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Fri, Feb 10, 2017 at 11:36 AM, Andrey Repin  wrote:
> Greetings, Gluszczak, Glenn!
>
>> Isn’t this a defect in cygpath?  Looks like memory corruption.
>
>> %%%cygpath -w /usr/non-existent/*
>> C:\cygwin\usr\non-existent\�[W��
>
> Looks more like private character space combined with incorrect terminal setup.

The link to private character space is realllly obscure. Firstly, the
commands that sometimes show failure have a '*' or splat in them. Bash
will try to convert a path with a splat in it to the list of matching
paths, if there are matches. If there aren't, then the argument seen
by the spawned program will contain a splat. Then the cygpath program
has to properly describe the path that contains the splat. The splat
is not a legal character IN A WINDOWS PATH, but a private character
could be and that's how terminal configuration enters in. Cygpath is
giving the string that would be used to represent the path, and that
string will contain a private use character.

In my testing, the environment has no LC variable set to anything, so
the locale mechanisms are presumably doing their default things. All
my attempts with this got a empty box character at first, if the
asterisk went through. That empty box character is presumably some
private use character that is supposed to substitute for an asterisk.
When I switched mintty's configuration to use Consolas, the
previously-run tests output was rerendered by mintty and the 'bad'
character rendered as a box with a question mark inside.

If I enter cygpath -w /usr/bin/* I get output consisting of all the
files in /usr/bin with their paths converted to Windows form. If I
escape the argument so globbing is not done, I get the strange output.

 cygpath -w '/usr/bin/*'
C:\cygwin\bin\

In the above the ticks around the path prevented the path from being
globbed. It might be considered unexpected though, that the path with
an asterisk would be treated as "The user desired to know what the
windows path to a file would be if it's cygwin path ended with an
asterisk". I think the odds of that user story are vanishingly small
compared to the odds of "What would a Windows path to a wildcard look
like that corresponds to this Cygwin wildcard?" But that's a design
problem.

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