From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by sourceware.org (Postfix) with ESMTPS id 0AAED385E001 for ; Sun, 22 Mar 2020 20:15:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0AAED385E001 Received: by mail-qt1-x830.google.com with SMTP id i3so6113415qtv.8 for ; Sun, 22 Mar 2020 13:15:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=H5Lgx0eoAWrCWPOnQEOqsjbxCSwDDNLLdxgfCjHmgxg=; b=WXJYbE5iM5dNI1q7IHA3Oi2wln3m0WzMVpJKOHY+EICuf+ndVpPx0CYFfAFLl4rJ7V qpMftIas+5qp3vu2gYU0w8sRCPIbKvpJlZWNhMmMr31HNgi4uA7n5yYLgQTelLaFjOrg 8I6QcHI+aA0ZltN10ga7e4hhfw/4Xq9NEFXj3ulRGD1FAUe/NfGCmpznQwXpItYrThzg n/ShhbEzMOyj5Q/cseCMdywl/b/b9BKamLQl1g1ecTsQlOjXcUWAwzSReecgHWVVMDC9 kzWuU2mQ+ge0ksw+jTwlD85/mv8ol3BkJpoFT/5fmVrWMLbHYhAjy1H5e9STmoX6PcNp fonA== X-Gm-Message-State: ANhLgQ0VbOFxecBuHXie3bqAz4vno474b2FPT384HwBI3UBoxQUJrC/F 7T3yZL7RqGNFi1zqqpn+Eamk6IozuBMVSgBSyB4= X-Google-Smtp-Source: ADFU+vs0zyBHLhA1dPd/j6uM3jGYXVpzX9NW4Lgpqx2IZ1h/qdAvrMiWK0FyI0a16n5T4V1LuZEo4izBjLdD9+t4z2U= X-Received: by 2002:aed:3f95:: with SMTP id s21mr4878057qth.347.1584908138610; Sun, 22 Mar 2020 13:15:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Moore Date: Sun, 22 Mar 2020 20:15:27 +0000 Message-ID: Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash To: Jay Libove Cc: "cygwin@cygwin.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_2, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 20:15:40 -0000 Interesting. Maybe codepage-related issues, then. Sorry, I'm out of my depth now, I'll leave it to someone else to diagnose further. On Sun, 22 Mar 2020 at 19:54, Jay Libove wrote: > > Good suggestion, deleting files one by one. It's not just one file, but i= t does seem to have something to do with some file name patterns. > I think I've got it. It's accented characters. > I live in Spain. Spanish has accented characters such as "Asociaci=C3=B3n= ". > When I remove all files containing any accented character in their name, = the problem goes away. > So the theory now is that the Cygwin argv-processing code has a problem w= ith =C3=A1ccented char=C3=A0cters ... > -Jay > > -----Original Message----- > From: Paul Moore > Sent: Sunday, 22 March 2020 20:42 > To: Jay Libove > Cc: cygwin@cygwin.com > Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No= such file or directory" in Windows CMD shell, but works okay in bash > > Have you tried deleting files one by one, to see if the issue is related = to a single file (sorry if this is an obvious suggestion that you've alread= y tried). > > In Cygwin bash, it's the shell that glob-expands wildcards before calling= your program (e.g. ls), and in find, it's the find code that does the glob= matching. But when running Cygwin utilities from a Windows shell, it's the= Cygwin argv-processing code linked into the executable that does the glob-= expansion. So it's reasonable to me that you should see the issue only with= CMD, and not with bash or find. But that only confirms what bit of code is= involved - not what the actual problem is :-( > > I don't actually know much about how the cygwin glob code actually works = (my main involvement with it has been to confirm that it doesn't suit my sp= ecific needs, and to work out a way to bypass it...) so I can only offer fa= irly basic suggestions, I'm afraid... > > Paul > > On Sun, 22 Mar 2020 at 19:27, Jay Libove wrote: > > > > Thanks Paul, both for your initial reply, and your follow-up. > > > > In this case it's not a matter case sensitivity. > > I've verified that, in one of the example cases, there are both *.pdf a= nd *.PDF files in the subject directory. > > Both 'ls *.pdf' and 'ls *.PDF' produce the "ls: cannot access '*.whatev= er': No such file or directory" error. > > > > (Nor, to the other respondent's question, as I pointed out in my origin= al post, is it ACLs, as I did check CACLS before posting). > > > > I also tried copying (using Windows CMD "COPY") *.pdf (so being under W= indows, not Cygwin, it matches all cases) from a subject directory to a new= test directory. > > In the resulting copy in the new test directory, the Cygwin shell expan= sion problem persists. > > > > Here's an interesting twist: > > C:> cd c:\bin\cygwin64\bin > > C:> ln gnufind.exe find.exe # I do this to allow me to differentiate be= tween Windows' built-in very limited FIND command, and GNU/Cygwin's far sup= erior find command. > > C:> cd \my\test\directory > > C:> gnufind . -name *.pdf -print > > [ successfully returns all *.pdf {lower case only} files in the > > subject directory ] C:> gnufind . -name *.PDF -print [ successfully > > returns all *.pdf {upper case only} files in the subject directory ] > > > > I'm pretty sure that Cygwin 'find' does NOT try to emulate shell globbi= ng the way 'ls' does, so it makes sense that this works, and it supports th= e theory that something weird is going on between how Cygwin does shell exp= ansion when under Windows CMD vs. when fully within the Cygwin environment = (under bash where of course bash is doing the shell expansion, and ls or ot= her Cygwin commands don't have to). > > > > Does any of this help pinpoint the problem further? > > > > thanks again, > > -Jay > > > > -----Original Message----- > > From: Paul Moore > > Sent: Sunday, 22 March 2020 20:09 > > To: Jay Libove > > Cc: cygwin@cygwin.com > > Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': > > No such file or directory" in Windows CMD shell, but works okay in > > bash > > > > Is this because cygwin globbing is (by default) case sensitive? You cou= ld set the CYGWIN environment variable to "glob:ignorecase" to get case-ins= ensitive behaviour. > > > > Paul > > > > On Sun, 22 Mar 2020 at 17:52, Jay Libove via Cygwin = wrote: > > > > > > I've never seen this before. > > > In a Windows CMD shell, Cygwin shell expansion, for example: > > > ls *.pdf > > > > > > returns: > > > ls: cannot access '*.PDF': No such file or directory (Indeed, any > > > Cygwin shell expansion, when executed from within Windows CMD, > > > produces this error. See below) > > > > > > ls *someotherwildcard* (that matches the same .pdf files) DOES return= the expected file list. > > > > > > Example: > > > > > > C:> DIR *.pdf > > > Volume in drive C is C > > > Volume Serial Number is 8674-712A > > > > > > Directory of C:\Temp > > > > > > 22/03/2020 18:30 1.675.954 test.pdf > > > XX/XX/XXXX XX:XX {Any many other .pdf files} > > > > > > Yet: > > > > > > C:> ls *.pdf > > > ls: cannot access '*.pdf': No such file or directory > > > > > > And: > > > C:> bash > > > user@hostname /cygdrive/C/Temp/test > > > $ ls *.pdf > > > A.pdf > > > B.pdf > > > {etc} > > > > > > And, not ALL of the *.pdf files in the particular directory where I'v= e encountered this trigger the problem... > > > > > > C:> ls N*.pdf > > > N.pdf > > > > > > C:> ls A*.pdf > > > ls: cannot access 'A*.pdf': No such file or directory > > > > > > Nor do all directories containing .pdf files produce this. Of the man= y thousands of files and directories that I have, only some produce this pr= oblem. > > > In others, ls *.pdf works perfectly in Windows CMD. > > > > > > I've looked at the Windows ATTRIB and CACLS of the files in directori= es where this problem occurs. > > > They're all the same. That is, uniform across all files and directori= es. Nothing interesting. > > > > > > It's not just 'ls': > > > > > > C:> cat *.pdf > > > cat: '*.pdf': No such file or directory > > > > > > So, it appears to be Cygwin shell expansion, when executed under Wind= ows CMD, which is provoking this strange behavior. > > > Any ideas what could be causing this, and how to solve it? > > > > > > many thanks, > > > Jay > > > > > > -- > > > Problem reports: https://cygwin.com/problems.html > > > FAQ: https://cygwin.com/faq/ > > > Documentation: https://cygwin.com/docs.html > > > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple