Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

2020-03-22 Thread Marco Atzeri via Cygwin
Am 22.03.2020 um 21:19 schrieb Yaakov Selkowitz: On Sat, 2020-03-21 at 07:40 +0100, Marco Atzeri via Cygwin wrote: Am 21.03.2020 um 05:55 schrieb Marco Atzeri: Am 20.03.2020 um 20:24 schrieb Hans-Bernhard Bröker: Am 20.03.2020 um 00:18 schrieb Brian Inglis: On 2020-03-18 23:25, Marco Atzeri v

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

2020-03-22 Thread Yaakov Selkowitz
On Sat, 2020-03-21 at 07:40 +0100, Marco Atzeri via Cygwin wrote: > Am 21.03.2020 um 05:55 schrieb Marco Atzeri: > > Am 20.03.2020 um 20:24 schrieb Hans-Bernhard Bröker: > > > Am 20.03.2020 um 00:18 schrieb Brian Inglis: > > > > On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote: > > > > > It seems

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

2020-03-22 Thread Paul Moore via Cygwin
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

Re: Why is taskset still not in util-linux?

2020-03-22 Thread Yaakov Selkowitz
On Sat, 2020-03-21 at 01:37 -0700, Mark Geisert wrote: > Eliot Moss wrote: > > On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote: > > > > > Cygwin doesn't support syscalls. I'd be very wary of any code which is > > > conditional on any #ifdef SYS_*. > > > > Of course. AFAICT taskset does not need

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

2020-03-22 Thread Jay Libove via Cygwin
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 ac

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

2020-03-22 Thread Paul Moore via Cygwin
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

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

2020-03-22 Thread Jay Libove via Cygwin
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

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

2020-03-22 Thread Paul Moore via Cygwin
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

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

2020-03-22 Thread Marco Atzeri via Cygwin
Am 22.03.2020 um 18:50 schrieb Jay Libove via Cygwin: 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, prod

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

2020-03-22 Thread Paul Moore via Cygwin
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

setup 2.904 release candidate - please test

2020-03-22 Thread Jon Turney
A new setup release candidate is available at: https://cygwin.com/setup/setup-2.904.x86_64.exe (64 bit version) https://cygwin.com/setup/setup-2.904.x86.exe(32 bit version) Please test, and report any problems here. This is not the place for setup feature requests. Changes compared t

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

2020-03-22 Thread Jay Libove via Cygwin
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

[ANNOUNCEMENT] Updated: gnupg2-2.2.20-1

2020-03-22 Thread Marco Atzeri via Cygwin-announce
Version 2.2.20-1 of gnupg2 is available in the Cygwin distribution: CHANGES Latest upstream security fix release https://lists.gnupg.org/pipermail/gnupg-announce/2020q1/000444.html DESCRIPTION The GNU Privacy Guard GnuPG is a command line tool without any graphical user interface. I

Re: New pty implementation is really slow

2020-03-22 Thread Thomas Wolff
Am 22.03.2020 um 06:51 schrieb Marco Atzeri via Cygwin: Am 22.03.2020 um 04:21 schrieb Joe via Cygwin: I'm using cygwin 3.1.4 on Windows 10. The new pseudo terminal stuff seems really slow. For example: $ time seq 1 (output omitted) real    0m23.510s user    0m1.515s sys 0m4.483s If I