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