bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

[Andrey Repin]

Greetings, L A Walsh!

> On 2020/03/24 00:18, Jay Libove via Cygwin wrote:
>> Problem:
>> Under certain circumstances (see Steps to Reproduce, below) Cygwin programs' built-in argv[] globbing will produce unexpected:
>> "{programName}: cannot access '{glob pattern}: No such file or directory"
>> e.g.
>> "ls: cannot access '*.pdf': No such file or directory"
>> .. despite the fact that e.g. *.pdf definitely exists.
>>   
> ----
>     This isn't a bug or a problem, it is working normally as expected.
> Cygwin programs don't have built-in argv[] globbing or processing.

>     The problem you are seeing is because you are calling cygwin programs
> from a windows shell.

>     On windows, every program has to be built with glob processing.

>     On unix, glob processing happens in the shell, so all unix 
> (linux+cygwin)
> type programs have no glob processing because they know that globbing is 
> built
> into the shell (like bash or csh, or dash, etc).

> If you run 'ls' *.pdf in bash, bash expands the *.pdf into arguments
> that don't contain a glob (if the glob matches a file).  So 'ls' sees
> only fixed filenames and no globs.

> When you run 'ls from the Windows shell, Windows cmd.exe doesn't expand
> glob chars into anything.  so 'ls' sees a literal file name of '*.pdf'.

> On linux you can name a file '*.pdf' (using an asterisk as a valid 
> character).
> Unless you have a file named, literally '*.pdf', ls won't see it.

That's not what actually happens.

...\Documents> ls -1 *.pdf
21927-ticket.pdf
'Stars! Universe Map.pdf'


-- 
With best regards,
Andrey Repin
Thursday, April 2, 2020 15:51:26

Sorry for my terrible english...