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

Hi Cygwin team, Here is a consolidated bug report based on the discussion in recent days which I'd started under the subject " shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash " (thread starter https://cygwin.com/p

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

that points towards a solution, but it certainly must be a clue. thanks, Jay -Original Message- From: Andrey Repin Sent: Monday 23 March 2020 18:44 To: Jay Libove ; cygwin@cygwin.com Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

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: cygw

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

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 t

shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

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* (tha

'whois' no longer following referrals ?

Once upon a time, the UNIX/cygwin ‘whois’ program would follow referrals. So, you could ask, for nearly any domain, ‘whois name.domain’ and whois would first find out which whois server could answer the question, and then would query that whois server and get the answer. Lately (months? more?),