public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Jay Libove <libove@felines.org>
To: "cygwin@cygwin.com" <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
Date: Sun, 22 Mar 2020 19:27:06 +0000	[thread overview]
Message-ID: <DM5PR13MB0876F96583BE7E4C47AF1E09CBF30@DM5PR13MB0876.namprd13.prod.outlook.com> (raw)
In-Reply-To: <CACac1F_rKFLb3dCj-ZQPW3CHo3gATo+H4FD+E+PB6y9d+uKN0A@mail.gmail.com>

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 and *.PDF files in the subject directory.
Both 'ls *.pdf' and 'ls *.PDF' produce the "ls: cannot access '*.whatever': No such file or directory" error. 

(Nor, to the other respondent's question, as I pointed out in my original post, is it ACLs, as I did check CACLS before posting).

I also tried copying (using Windows CMD "COPY") *.pdf (so being under Windows, 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 expansion 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 between Windows' built-in very limited FIND command, and GNU/Cygwin's far superior 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 globbing the way 'ls' does, so it makes sense that this works, and it supports the theory that something weird is going on between how Cygwin does shell expansion 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 other Cygwin commands don't have to).

Does any of this help pinpoint the problem further?

thanks again,
-Jay

-----Original Message-----
From: Paul Moore <p.f.moore@gmail.com> 
Sent: Sunday, 22 March 2020 20:09
To: Jay Libove <libove@felines.org>
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 could set the CYGWIN environment variable to "glob:ignorecase" to get case-insensitive behaviour.

Paul

On Sun, 22 Mar 2020 at 17:52, Jay Libove via Cygwin <cygwin@cygwin.com> 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've 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 many thousands of files and directories that I have, only some produce this problem.
> In others, ls *.pdf works perfectly in Windows CMD.
>
> I've looked at the Windows ATTRIB and CACLS of the files in directories where this problem occurs.
> They're all the same. That is, uniform across all files and directories. 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 Windows 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

  reply	other threads:[~2020-03-22 19:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-22 17:50 Jay Libove
2020-03-22 19:08 ` Paul Moore
2020-03-22 19:27   ` Jay Libove [this message]
2020-03-22 19:41     ` Paul Moore
2020-03-22 19:54       ` Jay Libove
2020-03-22 20:15         ` Paul Moore
2020-03-23 17:43         ` Andrey Repin
2020-03-23 18:34           ` Jay Libove
2020-03-23 19:13             ` Andrey Repin
2020-03-24  7:57               ` Thomas Wolff
2020-03-23 23:04             ` Marco Atzeri
2020-03-22 19:10 ` Marco Atzeri
2020-03-22 19:15   ` Paul Moore
2020-03-28 12:21 ` Andrey Repin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM5PR13MB0876F96583BE7E4C47AF1E09CBF30@DM5PR13MB0876.namprd13.prod.outlook.com \
    --to=libove@felines.org \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).