From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 74E42398D041 for ; Wed, 14 Jul 2021 23:07:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 74E42398D041 Received: by mail-wr1-x42e.google.com with SMTP id k4so5203345wrc.8 for ; Wed, 14 Jul 2021 16:07:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CFrmHwWfnY9K+ue8W/A9/y+VYaSz2Gqfdekd2mYRzVI=; b=L6jafgrQE9oKqeTalf7dvSeR8WRm9OsT9F35/Zne0VeTwfFmz8/mt3rn799T6dqq79 a32zrYZbC7goAGRW5lPqV1oN1734CdeEmxKpmuPptq9JsC92oVpFNJgFdz3xpPCMT111 FjeVf2k3FomW7Dv5pETBTLcJXPBnhiJTPcrGzqWK2wnJ8xbVaoRNcaLV7/wfFNThoKRL 2LnDRPgiCQFEXg2fhMfqWBu0TBugZWssb/Rjv5KhWfGSHPn5FTDtSQDeSk+a/TJuQVU0 CNvrFHfbVnO7UDXm1FSZ//veOGL1GqGj+0aR+FH2uT0CEXxRiT3G0j6eV1cHuYcse3Le e+NA== X-Gm-Message-State: AOAM533vtH4OlM+ZM07CiO6ZtZA0ku59aCW+LnWBdAbU7No4XVmFHqFI rML0yzKgiOBLAHVKp1Jhd7OqvoTUus4= X-Google-Smtp-Source: ABdhPJwtmSRMkYIm2Pz8EbkJn+Z2DFLjOn+749llH+tTTz9rezjL8Mstk4JoO3JZMILsWmQ4NNcfTQ== X-Received: by 2002:a5d:4c87:: with SMTP id z7mr504351wrs.405.1626304028445; Wed, 14 Jul 2021 16:07:08 -0700 (PDT) Received: from [192.168.0.2] (ip-89-176-51-83.net.upcbroadband.cz. [89.176.51.83]) by smtp.gmail.com with ESMTPSA id o22sm3270511wmc.18.2021.07.14.16.07.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jul 2021 16:07:07 -0700 (PDT) Subject: Re: cygpath and star character To: cygwin@cygwin.com References: <7fa873dc-e4cb-8217-5844-82db627bd871@gmail.com> From: Tomas Jura Message-ID: <435f5a07-98cc-ef48-2188-6289d7a9dd7f@gmail.com> Date: Thu, 15 Jul 2021 01:07:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 23:07:10 -0000 Hi My use case is building the CLASSPATH environment variable for java. Like: export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w 'my/java/jar/directory/*' )" CLASSPATH can contain the star character at the end on Windows. Example C:\Apps\java\lib\* , which means something different then just C:\Apps\java\lib, ie. the star is necessary there. Tomas  14. 07. 21 v 21:26 Ken Brown wrote: > On 7/14/2021 4:10 AM, Tomas Jura via Cygwin wrote: >> Hi >> >> I found a strange behaviour of the program cygpath program >> >> 0 >cygpath -w "./*/*"           <--- IMHO wrong output >>   \ >> >> 0 >cygpath -w "./*/*"  | od -a                   <--- a detailed dump >> 0000000   o nul   *   \   o nul   *  nl >> 0000010 > > What you're seeing here is a consequence of the way Cygwin handles > valid POSIX file names that contain characters (like '*') that are not > allowed in Windows file names.  See "Forbidden characters in > filenames" at > >   https://cygwin.com/cygwin-ug-net/using-specialnames.html > > Internally, Cygwin converts "./*/*" to the wide char string L"*\*" > with '*' replaced by 0xf02a.  This then gets converted to the > multibyte sequence in your "detailed dump", which is not quite > detailed enough: > > $ cygpath -w "./*/*"  | od -b > 0000000 357 200 252 134 357 200 252 012 > 0000010 > > I tend to agree that this is not desirable behavior.  I doubt if users > of 'cygpath -w' expect to get a result that contains transformed > forbidden characters.  But maybe there's a use case for this that I'm > missing.  Corinna? > >> 0 >cygpath -wp "./*/*"         <-- but this works as expected >> *\* >> >> Is this bug or expected behavior ? > > It looks to me like a bug that 'cygpath -w' and 'cygpath -wp' give > different results on a path that doesn't contain a colon. > > Ken