Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
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 via Cygwin wrote: It seems something is adding 5M or more to the normal size of the programs See attached for summary details by arch, but main points for both are, on x86_64: [...] Could this be due to the ginormous number of targets configured into the build? may be, as it also take ages to full compile with the current configuration: # --enable-shared CYGCONF_ARGS=" --enable-install-libiberty --disable-gdb --disable-libdecnumber --disable-readline --disable-sim --enable-64-bit-bfd --enable-targets=all " I am testing a build dropping the "enable-targets=all" and also forcing the "enable-shared" --enable-shared \ lt_cv_deplibs_check_method=pass_all If that doesn't work, feel free to borrow: thanks. It does not work. https://github.com/cygwinports/binutils/blob/master/2.24.51-shared-libs.patch However, these libraries are (by design) API-unstable, so is not recommended to allow other code to link against these shared libs, therefore I would also suggest: https://github.com/cygwinports/binutils/blob/master/binutils.cygport#L30-L38 understood Hoping it will note ages again "NOT take" dropping the target seems to work very well current version $ du -sb /usr/bin/gprof.exe 5424147 /usr/bin/gprof.exe under build $ du -sb gprof/gprof.exe 19968 gprof/gprof.exe in reality I was fooled by the stub, the stripped version is ~ 1M insted of 5M $ du -sb inst/usr/bin/gprof.exe 1146387 inst/usr/bin/gprof.exe any clue why we are using a "enable-targets=all" options ? Not sure, but if it's just so that 32-bit utils can read 64-bit binaries (which is useful), --enable-targets=x86_64-pep should be enough. there is a trace of previous setting before "all" in the cygport # --enable-targets=i686-efi-pe,x86_64-efi-pe,ia64-efi-elf,x86_64-pc-cygwin,i686-pc-cygwin Any cross compiler should use its own binutils not the cygwin one, correct ? Yes, regardless. -- Yaakov Thanks as usual Marco -- 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: Putting packages up for adoption
On Fri, 2020-03-20 at 10:29 +0100, Jan Nijtmans wrote: > Op vr 20 mrt. 2020 om 05:03 schreef Yaakov Selkowitz: > > To that end, in the best interest of the community, please consider my > > packages up for adoption. I don't expect that any one person will take > > all of them; some are obsolete and due for removal anyway, some should > > be picked up as soon as possible, and others might just end up > > bitrotting if nobody is interested in them. However, in whatever there > > is interest (or need), hopefully what is there now will serve as a > > strong foundation to on which to continue to build. > > I'm willing to adopt the tcl-related packages: > > mingw64-i686-tcl Yaakov Selkowitz > mingw64-i686-tk Yaakov Selkowitz > mingw64-x86_64-tcl Yaakov Selkowitz > mingw64-x86_64-tkYaakov Selkowitz > tcl Yaakov Selkowitz > tcl-itcl Yaakov Selkowitz > tcl-itk Yaakov Selkowitz > tcl-iwidgets Yaakov Selkowitz > tcl-tix Yaakov Selkowitz > tcl-tk Yaakov Selkowitz > tcl-togl Yaakov Selkowitz A word of caution wrt Tcl/Tk for Cygwin: upstream incorrectly treats Cygwin as a Win32 platform, necessitating extensive patches to make it comply with *NIX/X11 standards. These patches CANNOT be dropped without breaking compatibility, since Win32 and X11 APIs do not interact. Fortunately, Tcl/Tk moves rather slowly, so the existing patches should serve you well for some time. -- Yaakov
Re: Putting packages up for adoption
Yaakov Selkowitz writes: > Case sensitivity. The modules depend on symbols both from other > dependent modules as well as the C libraries which they bind. While > for many of the libraries these names are slightly different, e.g. > -lPango and -lpango-1.0, in the case of Cairo, the only difference is > case (-lCairo -lcairo). I'd seen that and then dismissed it… > FWIW I always ran Cygwin with case sensitivity > on (except when Windows upgrades forcibly disabled that behind my > back), as these issues are not infrequent particularly when building. I'm running into it for the first time… :-) > ExtUtils::Depends used to use full paths for the module imports, e.g. > /usr/lib/perl5//libPango.dll.a instead of -L/usr/lib/perl5/ > -lPango, but I guess that changed at some point. If building with case > sensitivity enabled is not an option, then I suggest patching EU::D to > use full paths for module imports again. It uses the pkgconf system it would appear, so I've monkey-patched cairo.pc accordingly. Not sure what will be the final solution. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
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 something is adding 5M or more to the normal > > > > > size of the programs > > > > > > > > See attached for summary details by arch, but main points for both > > > > are, on x86_64: > > > [...] > > > > > > Could this be due to the ginormous number of targets configured into > > > the build? > > > > may be, as it also take ages to full compile with the > > current configuration: > > > > # --enable-shared > > CYGCONF_ARGS=" > > --enable-install-libiberty > > --disable-gdb > > --disable-libdecnumber > > --disable-readline > > --disable-sim > > --enable-64-bit-bfd > > --enable-targets=all > > " > > > > I am testing a build dropping the "enable-targets=all" > > and also forcing the "enable-shared" > > > > --enable-shared \ > > lt_cv_deplibs_check_method=pass_all If that doesn't work, feel free to borrow: https://github.com/cygwinports/binutils/blob/master/2.24.51-shared-libs.patch However, these libraries are (by design) API-unstable, so is not recommended to allow other code to link against these shared libs, therefore I would also suggest: https://github.com/cygwinports/binutils/blob/master/binutils.cygport#L30-L38 > > Hoping it will note ages again > > "NOT take" > > dropping the target seems to work very well > > current version > $ du -sb /usr/bin/gprof.exe > 5424147 /usr/bin/gprof.exe > > under build > $ du -sb gprof/gprof.exe > 19968 gprof/gprof.exe > > any clue why we are using a "enable-targets=all" options ? Not sure, but if it's just so that 32-bit utils can read 64-bit binaries (which is useful), --enable-targets=x86_64-pep should be enough. > Any cross compiler should use its own binutils not the cygwin one, correct ? Yes, regardless. -- Yaakov -- 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
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
Re: Why is taskset still not in util-linux?
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 the syscall, it just needs the > > library call to work. Asking about the syscall is, I suppose, a kind of > > Linux > > shorthand to see if something is supported on the particular platform. > > Mark's > > suggestion of providing a fake definition of that syscall definition is a > > workaround that may disturb the util-linux sources the least. > > What I did here was definitely a hack. I'm not sure it's the best solution. > > I fully concur with Yaakov's warning. There's two levels to syscalls as seen > in > programs like taskset. On one level, configure checks whether a particular > syscall exists on the compiling machine because different Linux kernels have > different sets of syscalls. On the second level, the program actually uses a > call named syscall() to call into specific kernel routines. > > On Cygwin, what to do about programs that assume they're running on Linux and > so > make use of the Linux syscall feature? We could dummy up a sys/syscall.h but > implementing a full syscall() interface would be a lot of work and do nothing > but slow down programs making heavy use of it; it adds a layer of indirection. I have considered doing just that on multiple occasions, but never got so desperate for it to bother. Keep in mind that kernel APIs often vary from their userspace wrappers (which is one of the two reasons userspace code calls syscall, the other being to access yet-unwrapped calls), meaning such an implementation wouldn't be a simple mapping to existing userspace functions. However, I wouldn't worry so much about performance, the point would be compatibility. > Yaakov, do you have a general strategy for dealing with syscall usage when > you've come across it in all the porting you've done? Cygwin-specific patch? That depends very much on what the code is trying to do (and which syscalls it wants to call!), but using #ifdef SYS_* to guard use of the corresponding userspace function call might be a first. There are definitely some of my packages which I had to patch around syscall assumptions, but I'd have to go find them. -- Yaakov -- 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
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 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...
>
Re: Putting packages up for adoption
On Sun, 2020-03-22 at 17:36 +0100, ASSI wrote: > ASSI writes: > > I see the same thing. I have no idea why the linker doesn't pick up the > > reference, but it produces exactly the same error when removing > > "-lcairo" from the link list, which looks suspicious. > > Indeed if I replace that library reference with "-l:libcairo.dll.a" then > things work. The other cairo-dependent modules seem to have the same > problem. Could anybody with some more knowledge of binutils than me > explain why that happens and how to fix it? Case sensitivity. The modules depend on symbols both from other dependent modules as well as the C libraries which they bind. While for many of the libraries these names are slightly different, e.g. -lPango and -lpango-1.0, in the case of Cairo, the only difference is case (-lCairo -lcairo). FWIW I always ran Cygwin with case sensitivity on (except when Windows upgrades forcibly disabled that behind my back), as these issues are not infrequent particularly when building. ExtUtils::Depends used to use full paths for the module imports, e.g. /usr/lib/perl5//libPango.dll.a instead of -L/usr/lib/perl5/ -lPango, but I guess that changed at some point. If building with case sensitivity enabled is not an option, then I suggest patching EU::D to use full paths for module imports again. HTH, -- Yaakov
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,
RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash
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,
> 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
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,
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
any reason for NOT using a cygwin shell ?
for discrepancy check the ACLs of the files with "cacls"
--
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
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: Putting packages up for adoption
Marco Atzeri via Cygwin-apps writes: > I am planning to update all the packages left behind > by the Perl update > (Except if Achim is interested in them) > > perl-Glib already built > perl-Cairo > perl-Gtk2 > perl-Pango I currently have that stack in evaluation (since Pango needs those). It looks like I have most or all of the needed development libraries in my installation already. If that also holds true for the rest of the Gtk2 modules I'll just take them all… I'll look at Gtk3 and Gnome again later, give me a few days. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
setup 2.904 release candidate - please test
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 to 2.903: - The '--disable-old-keys' option is still accepted, but is now the default. - Add an '--enable-old-keys' option, for if you really need to install from an old mirror snapshot, for some reason. - The Start Menu folder used for 32-bit installs on WoW64 is now named 'Cygwin (32-bit)', to avoid collision with the name used for 64-bit installs. - Fix a memory allocation error which could (very rarely) cause crashes during package installation.
setup 2.904 release candidate - please test
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 to 2.903: - The '--disable-old-keys' option is still accepted, but is now the default. - Add an '--enable-old-keys' option, for if you really need to install from an old mirror snapshot, for some reason. - The Start Menu folder used for 32-bit installs on WoW64 is now named 'Cygwin (32-bit)', to avoid collision with the name used for 64-bit installs. - Fix a memory allocation error which could (very rarely) cause crashes during package installation. -- 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
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* (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
Re: Putting packages up for adoption
ASSI writes: > I see the same thing. I have no idea why the linker doesn't pick up the > reference, but it produces exactly the same error when removing > "-lcairo" from the link list, which looks suspicious. Indeed if I replace that library reference with "-l:libcairo.dll.a" then things work. The other cairo-dependent modules seem to have the same problem. Could anybody with some more knowledge of binutils than me explain why that happens and how to fix it? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: Putting packages up for adoption
Marco Atzeri via Cygwin-apps writes: > I already built > > perl-GLIB > perl-Cairo Yes, these are easy to build, I've even had the devel packages already installed. > but perl-Pango is failing > > [ LD blib/arch/auto/Pango/Pango.dll ] > /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: > xs/PangoCairo.o: in function > `gtk2perl_pango_cairo_shape_renderer_func': > /usr/src/debug/perl-Pango-1.227-3/xs/PangoCairo.xs:44: undefined > reference to `cairo_reference' > /usr/src/debug/perl-Pango-1.227-3/xs/PangoCairo.xs:44:(.text+0x21e): > relocation truncated to fit: R_X86_64_PC32 against undefined symbol > `cairo_reference' > > for what I see cairo_reference is in /usr/lib/libcairo.dll.a > So I am blocked and you can take over I see the same thing. I have no idea why the linker doesn't pick up the reference, but it produces exactly the same error when removing "-lcairo" from the link list, which looks suspicious. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Updated: gnupg2-2.2.20-1
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. It is an universal crypto engine which can be used directly from a command line prompt, from shell scripts, or from other programs. Therefore GnuPG is often used as the actual crypto backend of other applications. Full OpenPGP implementation (see RFC4880 at RFC Editor). Full CMS/X.509 (S/MIME) implementation. Ssh-agent implementation Runs on all Unix platforms, Windows and macOS. A full replacement of PGP; written from scratch. Does not use any patented algorithms. Freely available under the GPL; Can be used as a filter program. Better functionality than PGP with state of the art security features. Decrypts and verifies PGP 5, 6 and 7 messages. Supports RSA, ECDH, ECDSA, EdDSA, Elgamal, DSA, AES, Camellia, 3DES, Twofish, SHA2, and many more algorithms. Language support for a load of languages. Online help system. Optional anonymous message receivers. Integrated support for HKP keyservers (sks-keyservers.net). and many more things…. HOMEPAGE http://www.gnupg.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com .
[ANNOUNCEMENT] Updated: gnupg2-2.2.20-1
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. It is an universal crypto engine which can be used directly from a command line prompt, from shell scripts, or from other programs. Therefore GnuPG is often used as the actual crypto backend of other applications. Full OpenPGP implementation (see RFC4880 at RFC Editor). Full CMS/X.509 (S/MIME) implementation. Ssh-agent implementation Runs on all Unix platforms, Windows and macOS. A full replacement of PGP; written from scratch. Does not use any patented algorithms. Freely available under the GPL; Can be used as a filter program. Better functionality than PGP with state of the art security features. Decrypts and verifies PGP 5, 6 and 7 messages. Supports RSA, ECDH, ECDSA, EdDSA, Elgamal, DSA, AES, Camellia, 3DES, Twofish, SHA2, and many more algorithms. Language support for a load of languages. Online help system. Optional anonymous message receivers. Integrated support for HKP keyservers (sks-keyservers.net). and many more things…. HOMEPAGE http://www.gnupg.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- 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: New pty implementation is really slow
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 minimize the mintty window while seq is running, it gets slightly better: real 0m4.562s user 0m0.390s sys 0m1.202s But when I set CYGWIN=disable_pcon before starting mintty, I get: $ time seq 1 (output omitted) real 0m0.366s user 0m0.109s sys 0m0.093s So the new implementation seems to be over 60 times slower than the old one. -- only factor 10x on my test, amd only impacting mintty case Curious that 32bit disabled is 2x faster than 64bit disabled 64 bit Mintty with enabled (default) real 0m2.674s user 0m0.234s sys 0m0.859s mintty with disabled real 0m0.247s user 0m0.015s sys 0m0.046s CMD with enabled real 0m1.121s user 0m0.109s sys 0m0.187s CMD with disabled real 0m1.084s user 0m0.078s sys 0m0.312s 32 bit Mintty with enabled (default) real 0m2.548s user 0m0.281s sys 0m0.686s Mintty with disabled real 0m0.058s user 0m0.030s sys 0m0.000s CMD with enabled real 0m1.021s user 0m0.124s sys 0m0.296s CMD with disabled real 0m1.018s user 0m0.109s sys 0m0.265s I have the impression that the slow is due to some type of buffer expansion as I seem to notice a not uniform progress of the print the screen. But it could be just my eye... With disable_pcon, output is sent to mintty in bunches of 256 bytes at each read() invocation. With pcon enabled, typical output size is 12 bytes. That doesn't seem to be the whole story, though. Thomas -- 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
