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 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/ 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
--
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
Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash
On Sun, 22 Mar 2020 at 19:11, Marco Atzeri via Cygwin wrote: > any reason for NOT using a cygwin shell ? Many reasons. But that's not relevant to this thread, is it? (Note: I'm not the OP, just an interested contributor to the thread). I'm happy to elaborate if you want, but I suggest we do it under a different subject line. Paul -- 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
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 already 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 specific needs, and to work out a way to bypass it...) so I
can only offer fairly 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 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
> 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 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 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/ 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, whi
Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash
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 it
> 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ón".
> 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 with
> áccented charàcters ...
> -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 already
> 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 specific
> needs, and to work out a way to bypass it...) so I can only offer fairly
> 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 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
> > 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 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
> > 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
Can I find where cygwin is installed (for automation purposes)
I'm trying to write an automation script that works on a number of machines. I know that on all machines Cygwin will be installed, but I cannot guarantee that (1) it will be in the same location on each PC, or (2) that it will be in PATH. There's HKCU\Software\Cygwin\Installations, but that seems to use \?? prefixes on the PATH, which I'm not sure how to interpret (I know about \\?\ prefixes, but this is different, I assume?), and it also includes some non-Cygwin things (one machine I have, has \??\C:\PROGRA~1\ConEmu\ConEmu So far, the best I can see is to try every entry in there, strip \??, and look for a cygwin1.dll, and use the first entry I find that works. But that seems a bit arbitrary. Is there a better way? Thanks, Paul -- 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
Re: Can I find where cygwin is installed (for automation purposes)
On Wed, 15 Apr 2020 at 11:54, Csaba Ráduly via Cygwin wrote: > On my machine, I have a > > HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup > > key, which contains a string value named "rootdir" with the date > "C:\cygwin64". Thanks, that looks more useful. I didn't think to check there as I didn't recall having run the setup as "All users" so I assumed everything would be in HKCU. I should have checked! Paul -- 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
Re: Can I find where cygwin is installed (for automation purposes)
On Wed, 15 Apr 2020 at 13:43, Thomas Wolff wrote: > >> There's HKCU\Software\Cygwin\Installations, but that seems to use \?? > >> prefixes on the PATH, which I'm not sure how to interpret > Running that script within cygwin? `mount | grep " / "` As I said, I'm trying to find cygwin, so I can't run anything from within cygwin at this point :-( Paul -- 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
Re: Can I find where cygwin is installed (for automation purposes)
On Wed, 15 Apr 2020 at 16:54, Marco Atzeri via Cygwin wrote: > > Am 15.04.2020 um 15:29 schrieb Paul Moore via Cygwin: > > On Wed, 15 Apr 2020 at 11:54, Csaba Ráduly via Cygwin > > wrote: > > > >> On my machine, I have a > >> > >> HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup > >> > >> key, which contains a string value named "rootdir" with the date > >> "C:\cygwin64". > > > > Thanks, that looks more useful. I didn't think to check there as I > > didn't recall having run the setup as "All users" so I assumed > > everything would be in HKCU. I should have checked! > > Paul > > -- > > > Pay attention that Setup links to the last updated one 64 or 32bit > > Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Setup > Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cygwin\Setup > > Installations report all if more are installed (borderline case, maybe) > > Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations > Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cygwin\Installations > > both version 32 and 64 bit are reported on > > Computer\HKEY_CURRENT_USER\Software\Cygwin\Installations Thanks. Can you explain what the \?? prefix on the Installations values is about? I'm nervous that there's something going on there that means that just ignoring the first 3 characters isn't sufficient... ;-) Paul -- 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
Re: Can I find where cygwin is installed (for automation purposes)
On Wed, 15 Apr 2020 at 19:31, René Berber via Cygwin wrote: > > On 4/15/2020 1:10 PM, Paul Moore via Cygwin wrote: > > [snip] > > Thanks. Can you explain what the \?? prefix on the Installations > > values is about? I'm nervous that there's something going on there > > that means that just ignoring the first 3 characters isn't > > sufficient... ;-) > > https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats > > Look for "DOS device paths" Thanks. That's \\?\C:\... and what I'm seeing is \??\C:\... Is that just a typo/bug? That's the discrepancy that was confusing me :-( Paul -- 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
