From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112225 invoked by alias); 10 Feb 2017 20:37:23 -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 112216 invoked by uid 89); 10 Feb 2017 20:37:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=enters, firstly, Hx-languages-length:2269, W X-HELO: mail-ot0-f169.google.com Received: from mail-ot0-f169.google.com (HELO mail-ot0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Feb 2017 20:37:12 +0000 Received: by mail-ot0-f169.google.com with SMTP id 65so37208718otq.2 for ; Fri, 10 Feb 2017 12:37:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=SWktGcu23jaBREYujpIWrdv08EY44VqhVJtNmx+XeOY=; b=aMtPnJPjNd+ADz34LSVkKsxia3FhKDJPLhZ2jZXNcb3agiH19raFTbL7dzzDZeomPV Lo+rXmhpx9EI3gb5BWNFiTrS7qpJIfckGHkWAgWsqn8vwv1QX+qjO8Uop/nzYqrBvSUP Wkc1T4wg2J87anM81vkU9fezv+dmmSOb+WIbzlXT7VOhp0Y2jVBP9KYa7WjbS7hotHPA p84BEIzqN3TOgv7aou91Z7DCrS5wOzTsC+jlNbMVYtzF9ZKOASbnaPPZPUfIzywcr9uE p73gW2qIazpgZnYpy0xb2bJKEUu20JbmgcJQIu0EAMm2dQPT/STiKcAWPeu8ZXhMPvnp 0Jfg== X-Gm-Message-State: AMke39msxkf9u6aotZiUI07luKQ5lArs2prVDXYAADmRbv9zXWo3l8q2Ns96qNSfcbFMK6K81f8ec4SZwARFfQ== X-Received: by 10.157.27.70 with SMTP id l64mr5604712otl.92.1486759031265; Fri, 10 Feb 2017 12:37:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.12.166 with HTTP; Fri, 10 Feb 2017 12:37:10 -0800 (PST) In-Reply-To: <151946397.20170210223617@yandex.ru> References: <91DCAC3CB99C724EB365BB64677FBE7B139A86@MX204CL04.corp.emc.com> <151946397.20170210223617@yandex.ru> From: Michael Enright Date: Fri, 10 Feb 2017 20:37:00 -0000 Message-ID: Subject: Re: cygpath To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00137.txt.bz2 On Fri, Feb 10, 2017 at 11:36 AM, Andrey Repin wrote: > Greetings, Gluszczak, Glenn! > >> Isn=E2=80=99t this a defect in cygpath? Looks like memory corruption. > >> %%%cygpath -w /usr/non-existent/* >> C:\cygwin\usr\non-existent\=EF=BF=BD[W=EF=BF=BD=EF=BF=BD > > 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\=EF=80=AA 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