On 05.10.2020 17:20, Hamish McIntyre-Bhatty via Cygwin wrote:
On 02/10/2020 17:33, Marco Atzeri via Cygwin wrote:
On 02.10.2020 17:59, Hamish McIntyre-Bhatty via Cygwin wrote:
Hi,
I've noticed that cygcheck doesn't work when run against executables and
DLLs in the current working directory. Ha
On 02/10/2020 17:33, Marco Atzeri via Cygwin wrote:
> On 02.10.2020 17:59, Hamish McIntyre-Bhatty via Cygwin wrote:
>> Hi,
>>
>> I've noticed that cygcheck doesn't work when run against executables and
>> DLLs in the current working directory. Has anyone else experienced this?
>>
>> Hamish
>>
>>
>
On 02.10.2020 17:59, Hamish McIntyre-Bhatty via Cygwin wrote:
Hi,
I've noticed that cygcheck doesn't work when run against executables and
DLLs in the current working directory. Has anyone else experienced this?
Hamish
how are you calling it ?
$ cygcheck ./hello_c.exe
d:\cyg_pub\devel\ope
On Thu, 15 Mar 2018 23:40:55 +
Jon Turney <...> wrote:
> Just to be clear, the category is irrelevant here, it's the fact that
> xorgproto obsoletes these packages that is significant.
>
OK.
--
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygw
On 15/03/2018 18:21, Mikhail Usenko via cygwin wrote:
On Wed, 28 Feb 2018 22:57:05 +0100
Marco Atzeri <...> wrote:
Hi Mikhail,
as latest setup skips the installation of _obsolete packages
can you adjust the behaviour of cygcheck-dep to ignore
the false warning ?
/usr/bin/cygcheck-dep: WARNING
On Wed, 28 Feb 2018 22:57:05 +0100
Marco Atzeri <...> wrote:
> Hi Mikhail,
>
> as latest setup skips the installation of _obsolete packages
> can you adjust the behaviour of cygcheck-dep to ignore
> the false warning ?
>
> /usr/bin/cygcheck-dep: WARNING: broken dependencies:
> /usr/bin/cygcheck-
Greetings, Corinna Vinschen!
> On Feb 21 11:46, Andrey Repin wrote:
>> Greetings, Fergus Daly!
>>
>> >>> Cygcheck is a native Windows executable .. ..
>> >>> I pushed a fix and uploaded new developer snapshots to
>> >>> https://cygwin.de/snapshots/
>> >>> Please give them a try.
>>
>> > I tried
On Feb 21 09:17, Fergus Daly wrote:
> > For the third time, cygcheck is no Cygwin application, and unaware of Cygwin
> > paths.
> > Please give it native Windows paths.
>
>
> Thank you. Thank you. Thank you.
> [ You are usually so patient. :o( ]
> It seemed to me that a reasonable interpretation
> For the third time, cygcheck is no Cygwin application, and unaware of Cygwin
> paths.
> Please give it native Windows paths.
Thank you. Thank you. Thank you.
[ You are usually so patient. :o( ]
It seemed to me that a reasonable interpretation of the phrase
>>> I pushed a fix and uploaded new de
On Feb 21 07:46, Fergus Daly wrote:
> >> Cygcheck is a native Windows executable .. ..
> >> I pushed a fix and uploaded new developer snapshots to
> >> https://cygwin.de/snapshots/
> >> Please give them a try.
>
> I tried your link above but got "HTTP 404 Not found".
Duh, I did it again, didn't
On Feb 21 11:46, Andrey Repin wrote:
> Greetings, Fergus Daly!
>
> >>> Cygcheck is a native Windows executable .. ..
> >>> I pushed a fix and uploaded new developer snapshots to
> >>> https://cygwin.de/snapshots/
> >>> Please give them a try.
>
> > I tried your link above but got "HTTP 404 Not fo
Greetings, Fergus Daly!
>>> Cygcheck is a native Windows executable .. ..
>>> I pushed a fix and uploaded new developer snapshots to
>>> https://cygwin.de/snapshots/
>>> Please give them a try.
> I tried your link above but got "HTTP 404 Not found".
> Just in case this was your intention I tried
>> Cygcheck is a native Windows executable .. ..
>> I pushed a fix and uploaded new developer snapshots to
>> https://cygwin.de/snapshots/
>> Please give them a try.
I tried your link above but got "HTTP 404 Not found".
Just in case this was your intention I tried the latest cygwin1.dll
snapshot f
On Feb 15 14:58, Fergus Daly wrote:
> I have an executable (created in Cygwin) located on a mobile drive D:
>
> $ ls -al /cygdrive/d/src/sc.exe
> -rwxr-xr-x 1 ferg dell 1426958 Jan 28 17:44 /cygdrive/d/src/sc.exe*
> $ cygcheck /cygdrive/d/src/sc.exe
> d:\src\sc.exe
> D:\consoleX\bin\cygwin1.dll
>
Greetings, Fergus Daly!
> $ ls -al /d/src/sc.exe
> -rwxr-xr-x 1 ferg dell 1426958 Jan 28 17:44 /d/src/sc.exe*
> $ cygcheck /d/src/sc.exe
> cygcheck: could not find '/d/src/sc.exe'
> Why can't cygcheck find the file?
> (Particularly, when ls can. And so can, say, md5sum.)
Nice once. Can confirm.
On 2017-09-15 13:38, Nellis, Kenneth wrote:
> I found it surprising that the packages aren't listed in the order requested:
>
> $ cygcheck -f `which bash find grep xargs cygwin1.dll`
> bash-4.4.12-3
> cygwin-2.9.0-3
> findutils-4.6.0-1
> findutils-4.6.0-1
> grep-3.0-2
> $
>
> Adds a bit of challe
On 15/09/2017 21:38, Nellis, Kenneth wrote:
I found it surprising that the packages aren't listed in the order requested:
$ cygcheck -f `which bash find grep xargs cygwin1.dll`
bash-4.4.12-3
cygwin-2.9.0-3
findutils-4.6.0-1
findutils-4.6.0-1
grep-3.0-2
$
Adds a bit of challenge to match the out
>Looked, but didn't see this addressed in the archives...
>Just realized that cygcheck output contains DOS line endings forcing me to
>pipe it through d2u in certain applications. Wondering if this is intended or
>desired behavior. It is installed in /usr/bin, so I would expect to behave
>Unix-l
On Mon, 30 Jan 2017 18:30:19, Jon Turney wrote:
> I added a workaround to the script so that corresponding decoding ('+'
> -> ' ') is skipped if it looks like a cygcheck request ('text=1'), so
> this should be working again
Confirmed fixed, thanks.
--
Problem reports: http://cygwin.com/p
On 28/01/2017 03:01, Steven Penny wrote:
On Mon, 27 Jan 2014 16:43:23, Steven Penny wrote:
$ cygcheck -p 'g\x2b\x2b.exe'
I think this relies on this being interpreted as a PCRE regex, which
hasn't been the case for a while, since some server-side changes.
It looks like this is broken a
On 2017-01-28 12:06, Eric Blake wrote:
> On 01/28/2017 11:45 AM, Brian Inglis wrote:
>>> it did put me on the right track:
>>> $ cygcheck -p 'mingw32-g[:punct:][:punct:]' | awk 'NR>1{$0=$1}1'
>> Your command is the same as:
>> $ cygcheck -p mingw32-g[:ctnpu][:ctnpu] | sed '2,$s/\s.*//'
> Not ne
On 01/28/2017 11:45 AM, Brian Inglis wrote:
>> it did put me on the right track:
>> $ cygcheck -p 'mingw32-g[:punct:][:punct:]' | awk 'NR>1{$0=$1}1'
> Your command is the same as:
>
> $ cygcheck -p mingw32-g[:ctnpu][:ctnpu] | sed '2,$s/\s.*//'
Not necessarily. You forgot quotes, so dependin
On 2017-01-28 05:21, Steven Penny wrote:
> On Fri, 27 Jan 2017 21:01:14, Doug Henderson wrote:
>> Try this:
>> $ cygcheck -p "mingw32-g[*-,][*-,]"
>> Found 4 matches for mingw32-g[*-,][*-,]
> Thanks for this. Using ranges is gross, because it relies on your locale, but
> it did put me on the right
On Fri, 27 Jan 2017 21:01:14, Doug Henderson wrote:
> Try this:
> $ cygcheck -p "mingw32-g[*-,][*-,]"
> Found 4 matches for mingw32-g[*-,][*-,]
Thanks for this. Using ranges is gross, because it relies on your locale, but
it did put me on the right track:
$ cygcheck -p 'mingw32-g[:punct:][:pu
On 27 January 2017 at 20:01, Steven Penny wrote:
> On Mon, 27 Jan 2014 16:43:23, Steven Penny wrote:
>> $ cygcheck -p 'g\x2b\x2b.exe'
>
> It looks like this is broken again. package-grep does work:
>
> $ q=https://cygwin.com/cgi-bin2/package-grep.cgi
> $ curl -s "$q"'?text=1&arch=x86_64&grep=mi
On Mon, 27 Jan 2014 16:43:23, Steven Penny wrote:
> $ cygcheck -p 'g\x2b\x2b.exe'
It looks like this is broken again. package-grep does work:
$ q=https://cygwin.com/cgi-bin2/package-grep.cgi
$ curl -s "$q"'?text=1&arch=x86_64&grep=mingw32-g%2B%2B' | awk 'NR>1{$0=$1}1'
Found 4 matches for ming
On 1/17/2017 4:44 PM, Nellis, Kenneth (Conduent) wrote:
> From: Brian Inglis
>> On 2017-01-17 13:21, Marco Atzeri wrote:
>>> On 17/01/2017 21:00, Brian Inglis wrote:
All cygcheck output seems to have DOS line terminators in both
Cygwin 64 & 32.
Is this by design or just because it's
From: Brian Inglis
> On 2017-01-17 13:21, Marco Atzeri wrote:
> > On 17/01/2017 21:00, Brian Inglis wrote:
> >> All cygcheck output seems to have DOS line terminators in both
> >> Cygwin 64 & 32.
> >> Is this by design or just because it's a native Windows app?
> > second one
>
> So by accident r
On 2017-01-17 13:21, Marco Atzeri wrote:
> On 17/01/2017 21:00, Brian Inglis wrote:
>> All cygcheck output seems to have DOS line terminators in both
>> Cygwin 64 & 32.
>> Is this by design or just because it's a native Windows app?
> second one
So by accident rather than intent?
Could that be eas
On 17/01/2017 21:00, Brian Inglis wrote:
All cygcheck output seems to have DOS line terminators in both Cygwin 64 & 32.
Is this by design or just because it's a native Windows app?
second one
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http:
On Jul 18, 2016, at 10:27 AM, Marco Atzeri wrote:
>
> On 18/07/2016 17:46, Warren Young wrote:
>> While examining someone’s checkcheck -rsv output, I failed to find a simple
>> statement telling me which word size the DLL was built for.
>
> For 32 bit cygwin running under 64 system
> The hint i
On 18/07/2016 17:46, Warren Young wrote:
While examining someone’s checkcheck -rsv output, I failed to find a simple
statement telling me which word size the DLL was built for.
I was able to puzzle it out based on hints in the file, such as that “cygwin32”
packages means he has the 32-bit cros
Nellis, Kenneth xerox.com> writes:
> $ cygcheck -f `which procps`
$ cygcheck -f /bin/procps
procps-3.2.8-5
That's a bit of a packaging non-conformance (same for /bin/prockill).
Regards,
Achim.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/
On Tue, 10/21/14, Corinna Vinschen wrote:
> I also created a new snapshot
> on https://cygwin.com/snapshots/ which
> comes with a cygcheck containing that patch.
Thanks, Corinna! Now I can get back to debugging my real issue! :-)
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Oct 21 04:03, Andrew Schulman wrote:
> > Instead, I found that COMSPEC needs to be set in the environment or I get a
> > segfault as shown in my previous email below. I don't know why that is,
> > but I can easily demonstrate it.
>
> Confirmed here. I had actually already seen this segfault
> Instead, I found that COMSPEC needs to be set in the environment or I get a
> segfault as shown in my previous email below. I don't know why that is,
> but I can easily demonstrate it.
Confirmed here. I had actually already seen this segfault too, but I
hadn't figured out it was caused by em
---
> From: Marco Atzeri
> To: cygwin@cygwin.com
> Cc:
> Sent: Friday, October 17, 2014 11:59 PM
> Subject: Re: cygcheck -s segfaults in cygwin64 on Win7Pro-64
>
> On 10/17/2014 11:52 PM, John Wiersba wrote:
>> With a 3-week-old (i.e. recent) install of cygw
On 10/17/2014 11:52 PM, John Wiersba wrote:
With a 3-week-old (i.e. recent) install of cygwin, which otherwise functions
well:
$ uname -a
CYGWIN_NT-6.1 DESKTOP-NAME 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin
$ PATH=/bin:/usr/bin cygcheck -s
Cygwin Configuration Diagnostics
Current Syst
On Sun, Aug 3, 2014 at 5:34 PM, Yaakov Selkowitz <> wrote:
> On 2014-08-03 17:55, Doug Henderson wrote:
>>
>> cygcheck -p segment faults on my laptop where I have only installed
>> the 64-bit version of cygwin.
>
>
> How are you calling cygcheck -p?
>
>> Note: this install is the first and only ins
On 2014-08-03 17:55, Doug Henderson wrote:
cygcheck -p segment faults on my laptop where I have only installed
the 64-bit version of cygwin.
How are you calling cygcheck -p?
Note: this install is the first and only install of any version of
cygwin on this machine.
Your installation is actua
On Apr 23 23:25, Doug Henderson wrote:
> On Wed, Apr 23, 2014 at 9:44 AM, Corinna Vinschen wrote:
> > On Apr 23 09:17, Doug Henderson wrote:
> >> I am trying to identify the package containing the strings executable.
> >>
> >> $ uname -a
> >> CYGWIN_NT-6.1 Rover 1.7.29(0.272/5/3) 2014-04-07 13:46 x
On Wed, Apr 23, 2014 at 10:17 AM, Doug Henderson wrote:
> $ cygcheck -p strings.exe
> Segmentation fault
As a workaround you can use
$ set strings.exe
$ curl "cygwin.com/cgi-bin2/package-grep.cgi?text=1&arch=x86_64&grep=$1"
Or
$ apt-cyg searchall strings.exe
--
Problem reports:
From: Doug Henderson
>
> I am trying to identify the package containing the strings executable.
$ cygcheck -f `which strings`
binutils-2.24.51-2
$
--Ken Nellis
On Apr 23 09:17, Doug Henderson wrote:
> I am trying to identify the package containing the strings executable.
>
> $ uname -a
> CYGWIN_NT-6.1 Rover 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 Cygwin
>
> $ cygcheck -p strings.exe
> Segmentation fault
>
> After installing the binutils package (whic
On 01/02/2014 22:48, Mikhail Usenko wrote:
On Sat, 01 Feb 2014 12:16:02 +0100
Marco Atzeri <...> wrote:
On
CYGWIN_NT-6.1-WOW64 1.7.27(0.271/5/3) 2013-12-09 11:57 i686 Cygwin
(same on 20140128 snapshot)
$ cygcheck-dep diffutils
/usr/bin/cygcheck-dep: line 345: /dev/fd/62: No such file or d
On Sat, 01 Feb 2014 12:16:02 +0100
Marco Atzeri <...> wrote:
>
> On
> CYGWIN_NT-6.1-WOW64 1.7.27(0.271/5/3) 2013-12-09 11:57 i686 Cygwin
> (same on 20140128 snapshot)
>
>
> $ cygcheck-dep diffutils
> /usr/bin/cygcheck-dep: line 345: /dev/fd/62: No such file or directory
> /usr/bin/cygcheck-dep
On Sat, 01 Feb 2014 12:16:02 +0100
Marco Atzeri <...> wrote:
>
> On
> CYGWIN_NT-6.1-WOW64 1.7.27(0.271/5/3) 2013-12-09 11:57 i686 Cygwin
> (same on 20140128 snapshot)
>
>
> $ cygcheck-dep diffutils
> /usr/bin/cygcheck-dep: line 345: /dev/fd/62: No such file or directory
> /usr/bin/cygcheck-dep
On Mon, Jan 27, 2014 at 9:47 AM, Gates, Roger wrote
> $ ascii +
It should be noted that "ascii" is not included with a base install, and part of
the "ascii" package
> $ cygcheck -p 'g\x{2b}\x{2b}.exe'
it should be further noted that the braces are not necessary in this instance
$ cygcheck -
On 1/27/2014 10:47 AM, Gates, Roger wrote:
$ ascii +
ASCII 2/11 is decimal 043, hex 2b, octal 053, bits 00101011: prints as `+'
Official name: Plus Sign
Other names: Add, Cross
$ cygcheck -p 'g\x{2b}\x{2b}.exe'
Found 11 matches for g\x{2b}\x{2b}.exe
But of course, everyone knows that! ;-)
Th
On Friday, January 24, 2014 9:26 PM Steven Penny wrote
>On Wed, Jan 22, 2014 at 10:05 AM, David Boyce wrote
>> How about 'g[+][+]' or 'g[+]{2}'?
>
>Please, no more lazy answers
>
>$ cygcheck -p 'g[+][+].exe'
>Found 0 matches for g[ ][ ].exe
$ ascii +
ASCII 2/11 is decimal 043, hex 2b, oct
On Wed, Jan 22, 2014 at 10:05 AM, David Boyce wrote
> How about 'g[+][+]' or 'g[+]{2}'?
Please, no more lazy answers
$ cygcheck -p 'g[+][+].exe'
Found 0 matches for g[ ][ ].exe
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documen
On Wed, Jan 22, 2014 at 7:07 AM, Christopher Faylor wrote:
> So I'll change my answer to "I don't know".
How about 'g[+][+]' or 'g[+]{2}'?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Un
On 1/22/2014 11:05 AM, David Boyce wrote:
On Wed, Jan 22, 2014 at 7:07 AM, Christopher Faylor wrote:
So I'll change my answer to "I don't know".
How about 'g[+][+]' or 'g[+]{2}'?
May I suggest that curious folks can more directly validate workarounds
by trying them directly. cygwin.com gen
> On Wed, Jan 22, 2014 at 06:34:49AM -0500, Andrew Schulman wrote:
> >> >$ cygcheck -p 'g\+\+.exe'
> >> >Found 0 matches for g\ \ .exe
> >> >
> >> >How can I include a literal '+' (plus character) in my search?
> >>
> >> By remembering that this is a regex search. How do you quote special
On Wed, Jan 22, 2014 at 06:34:49AM -0500, Andrew Schulman wrote:
>> >$ cygcheck -p 'g\+\+.exe'
>> >Found 0 matches for g\ \ .exe
>> >
>> >How can I include a literal '+' (plus character) in my search?
>>
>> By remembering that this is a regex search. How do you quote special
>> character
> >$ cygcheck -p 'g\+\+.exe'
> >Found 0 matches for g\ \ .exe
> >
> >How can I include a literal '+' (plus character) in my search?
>
> By remembering that this is a regex search. How do you quote special
> characters
> in regexes? Answer: With a '\'.
That's what he did. The single qu
On 22/01/2014 06:58, Christopher Faylor wrote:
On Tue, Jan 21, 2014 at 05:59:16PM -0600, Steven Penny wrote:
Searching for the popular compiler produces unexpected results
$ cygcheck -p 'g++.exe'
Found 0 matches for g .exe
$ cygcheck -p 'g\+\+.exe'
Found 0 matches for g\ \ .ex
On Tue, Jan 21, 2014 at 05:59:16PM -0600, Steven Penny wrote:
>Searching for the popular compiler produces unexpected results
>
>$ cygcheck -p 'g++.exe'
>Found 0 matches for g .exe
>
>$ cygcheck -p 'g\+\+.exe'
>Found 0 matches for g\ \ .exe
>
>How can I include a literal '+' (plus
On Nov 19 16:08, Warren Young wrote:
> On 11/19/2013 10:13, Corinna Vinschen wrote:
> >
> >Why do they have to make such a mess out of a simple function like
> >GetVersionEx?
>
> Backwards compatibility at all costs?
Right. I'm just glad the native API is more reliable.
> >How dense is that?
>
On Wed, Nov 20, 2013 at 12:41 AM, Jim Garrison wrote:
(snip)
>> On Nov 19 14:20, Larry Hall (Cygwin) wrote:
>>
>> I found what happened:
>> http://msdn.microsoft.com/en-
>> us/library/windows/desktop/dn302074%28v=vs.85%29.aspx
>
> Hmm... from the quoted link:
>
> We have made some significant
> On Nov 19 14:20, Larry Hall (Cygwin) wrote:
> > On 11/19/2013 2:03 PM, Corinna Vinschen wrote:
> > >Looks like it, yes. What on earth were they thinking?
> >
> > Who says they were thinking? ;-)
>
> Point.
>
> I found what happened:
> http://msdn.microsoft.com/en-
> us/library/windows/desktop/
On 11/19/2013 10:13, Corinna Vinschen wrote:
Why do they have to make such a mess out of a simple function like
GetVersionEx?
Backwards compatibility at all costs?
How dense is that?
Manifest Density.
(American joke.)
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Nov 19 22:51, Corinna Vinschen wrote:
> On Nov 20 00:59, Andrey Repin wrote:
> > Greetings, Corinna Vinschen!
> >
> > > Why isn't there at least an additional non-manifest way to claim
> > > compatibility with the current OS? :(
> >
> > Because this "claim" is informational, or at least it sho
On Nov 20 00:59, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> > Why isn't there at least an additional non-manifest way to claim
> > compatibility with the current OS? :(
>
> Because this "claim" is informational, or at least it should be.
But apparently it isn't. It's enforced.
Howe
Greetings, Corinna Vinschen!
> Why isn't there at least an additional non-manifest way to claim
> compatibility with the current OS? :(
Because this "claim" is informational, or at least it should be.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 20.11.2013, <00:56>
Sorry for my terrible english.
On Nov 19 21:29, Corinna Vinschen wrote:
> On Nov 19 14:20, Larry Hall (Cygwin) wrote:
> > On 11/19/2013 2:03 PM, Corinna Vinschen wrote:
> > >On Nov 19 13:21, Charles Wilson wrote:
> > >>On 11/19/2013 12:13 PM, Corinna Vinschen wrote:
> > >>>Why do they have to make such a mess out of a simple fun
On Nov 19 14:20, Larry Hall (Cygwin) wrote:
> On 11/19/2013 2:03 PM, Corinna Vinschen wrote:
> >On Nov 19 13:21, Charles Wilson wrote:
> >>On 11/19/2013 12:13 PM, Corinna Vinschen wrote:
> >>>Why do they have to make such a mess out of a simple function like
> >>>GetVersionEx? It returns different
On 11/19/2013 2:03 PM, Corinna Vinschen wrote:
On Nov 19 13:21, Charles Wilson wrote:
On 11/19/2013 12:13 PM, Corinna Vinschen wrote:
Why do they have to make such a mess out of a simple function like
GetVersionEx? It returns different OS version numbers based on the
existence of a manifest in
On Nov 19 13:21, Charles Wilson wrote:
> On 11/19/2013 12:13 PM, Corinna Vinschen wrote:
> >Why do they have to make such a mess out of a simple function like
> >GetVersionEx? It returns different OS version numbers based on the
> >existence of a manifest in the executable. How dense is that?
> >
On 11/19/2013 12:13 PM, Corinna Vinschen wrote:
Why do they have to make such a mess out of a simple function like
GetVersionEx? It returns different OS version numbers based on the
existence of a manifest in the executable. How dense is that?
So we have thousands of executables, none of them
On Nov 19 09:37, Warren Young wrote:
> On 11/19/2013 03:03, Corinna Vinschen wrote:
> >
> >I'm also going
> >to look for a solution to differ between Windows 8 and 8.1 (also 2012
> >vs. 2012R2) in the cygcheck output.
>
> GetVersionEx() should do it: http://goo.gl/DbhsRJ
>
> If you follow the lin
On 11/19/2013 03:03, Corinna Vinschen wrote:
I'm also going
to look for a solution to differ between Windows 8 and 8.1 (also 2012
vs. 2012R2) in the cygcheck output.
GetVersionEx() should do it: http://goo.gl/DbhsRJ
If you follow the link to the OSVERSIONINFO structure, you will find a
table
On Nov 18 21:35, Gabriel Marcano wrote:
> cygcheck -svc causes a segfault on Windows 8.1 on line 1610 of cygcheck.cc,
> based on gdb output. I'm including some gdb output below that showcases this
> issue:
>
>
> 1610 strcat (osname, products[prod]);
> (gdb) list
> 1605
Bob, I've uninstalled w3m-img from my primary desktop machine (where
w3m page loads were slow) and now w3m is back to its original fast
speed.
Before uninstalling, I took the liberty of renaming
/usr/lib/w3m/w3mimgdisplay.exe to something else, and noticed an
instant speed improvement in w3m after
Hi Bob,
Thanks for your reply above.
I have not uninstalled w3m-img at this point, but will do so on
Monday. As far as Cygwin-X goes, it normally isn't running. I run
w3m and all Cygwin utilities in a PuttyCyg terminal screen.
I have the usual quick w3m speeds on a PC at home with an older
ver
On Fri, Nov 2, 2012 at 1:12 PM, Keith Christian wrote:
> I have some timing data courtesy of Sysinternals Procmon that has the
> time from invocation of w3m to display at 6 to 7 seconds, if that
> helps any. Package: w3m-0.5.3-2 was installed a few days ago, haven't
> noticed any load time changes
On Thu, Oct 25, 2012 at 9:20 AM, Bob Heckel wrote:
> I just noticed that uninstalling w3m-img reduces w3m's local file load time.
>
> Still working on repackaging to possibly address the other issue.
Hi Bob,
I have some timing data courtesy of Sysinternals Procmon that has the
time from invocat
On Wed, Oct 24, 2012 at 12:54 PM, Bob Heckel wrote:
> On Wed, Oct 24, 2012 at 12:28 PM, Keith Christian wrote:
>>
>> Summarizing: "w3m foo.html" has a second or two delay, but "w3m
>> foo.html > foo.output"or "w3m foo.html | less" is near-instantaneous.
>
> Ah, my benchmarks were based on redirecti
On Wed, Oct 24, 2012 at 12:28 PM, Keith Christian
wrote:
>
> Summarizing: "w3m foo.html" has a second or two delay, but "w3m
> foo.html > foo.output"or "w3m foo.html | less" is near-instantaneous.
Ah, my benchmarks were based on redirecting a large file so that makes sense.
Let me look at this a
On Tue, Oct 23, 2012 at 4:18 PM, Keith Christian
wrote:
> w3m works, but appears to run slowly after the last update. While
> comparing the output of "cygcheck -s -r -v" I noticed some
> differences.
The slowness mentioned above is the delay before the web page is
displayed, even when looking at
On Oct 23 19:07, Bob Heckel wrote:
> On Tue, Oct 23, 2012 at 6:18 PM, Keith Christian wrote:
> >
> > w3m works, but appears to run slowly after the last update. While
> > comparing the output of "cygcheck -s -r -v" I noticed some
> > differences.
>
> Sorry you're having trouble. Strange, I did b
On Tue, Oct 23, 2012 at 7:07 PM, Bob Heckel wrote:
> On Tue, Oct 23, 2012 at 6:18 PM, Keith Christian wrote:
>>
>> w3m works, but appears to run slowly after the last update. While
>> comparing the output of "cygcheck -s -r -v" I noticed some
>> differences.
>
> Sorry you're having trouble. Stran
On Tue, Oct 23, 2012 at 6:18 PM, Keith Christian wrote:
>
> w3m works, but appears to run slowly after the last update. While
> comparing the output of "cygcheck -s -r -v" I noticed some
> differences.
Sorry you're having trouble. Strange, I did benchmarking in
development and found 0.5.3 slight
On Oct 17 09:10, Denis Excoffier wrote:
> Hi,
>
> With the last snapshot (2012-10-16), the cygcheck.exe
> does not load (return code 127 under tcsh). Microsoft loader (ie
> double-click) on it says (i translate from french):
> _get_output_format: entry point not found in msvcrt.dll
>
> I recompil
22.09.2011 15:43, Marco atzeri пишет:
On 9/22/2011 2:10 PM, Oleksandr Gavenko wrote:
So 'cygcheck -f' does not allow 'glob' and 'regex'.
I write simple script that allow use regex:
#!/bin/sh
regex=$(echo "$1" | sed -e 's|\\|&&|g' -e 's|=|\\=|g')
for file in /etc/setup/*.lst.gz; do
name=${fil
On 9/22/2011 2:10 PM, Oleksandr Gavenko wrote:
$ time cygcheck -f 'stdio.h'
real 0m1.016s
user 0m0.031s
sys 0m0.015s
$ time cygcheck -f '*stdio.h'
$ time cygcheck -f '*stdio.h'
$ time cygcheck -f '*stdio.h'
$ time cygcheck -f /usr/include/stdio.h
cygwin-1.7.9-1
real 0m0.907s
user 0m0.015s
sys 0m
On Sat, Feb 26, 2011 at 4:38 PM, Corinna Vinschen wrote:
> On Feb 26 13:33, marco atzeri wrote:
>> On recent snapshots I noticed that
>> cygcheck is reporting as missing the files under the mount points
>> /usr/bin
>> /usr/lib
>>
>> $ mount
>> E:/cygwin2/bin on /usr/bin type ntfs (binary,auto)
>>
On Feb 26 13:33, marco atzeri wrote:
> On recent snapshots I noticed that
> cygcheck is reporting as missing the files under the mount points
> /usr/bin
> /usr/lib
>
> $ mount
> E:/cygwin2/bin on /usr/bin type ntfs (binary,auto)
> E:/cygwin2/lib on /usr/lib type ntfs (binary,auto)
> E:/cygwin2 on
On Sat, Dec 11, 2010 at 09:37:07PM -0800, Kenneth Wolcott wrote:
>Hi;
>
>On Sat, Dec 11, 2010 at 17:43, Jeffrey Walton wrote:
>> Hi All,
>>
>> Windows XP, fully patched. Cygwin, latest download from website
>> (installed today).
>>
>> It appears cygcheck times out on Windows XP. The timeout occurs
Hi;
On Sat, Dec 11, 2010 at 17:43, Jeffrey Walton wrote:
> Hi All,
>
> Windows XP, fully patched. Cygwin, latest download from website
> (installed today).
>
> It appears cygcheck times out on Windows XP. The timeout occurs with
> the Windows firewall up and down. Other downloads are function fin
Andrey Repin wrote:
Greetings, Csaba Raduly!
...
The API can handle "/" as the path separator, but cmd.exe can't.
You're seriously wrong...
How? (Which part is wrong?)
The Start menu's Run... command accepts forward slashes, and cmd.exe
parses unquoted forward slashes as parameter delimi
Greetings, Csaba Raduly!
> On Thu, Oct 21, 2010 at 4:46 AM, Andrey Repin wrote:
>>
>> Not to mention, the Windows itself don't see much of a difference between "/"
>> and "\" in path. (where it see, it is a bug).
> The API can handle "/" as the path separator, but cmd.exe can't.
You're seriousl
On Thu, Oct 21, 2010 at 4:46 AM, Andrey Repin wrote:
>
> Not to mention, the Windows itself don't see much of a difference between "/"
> and "\" in path. (where it see, it is a bug).
The API can handle "/" as the path separator, but cmd.exe can't.
--
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++
On Thu, Oct 21, 2010 at 06:46:16AM +0400, Andrey Repin wrote:
>Greetings, Christopher Faylor!
>
>>>[snip...]
a...@dstar ~
$ ln -s `which cmd.exe` cmd.exe
a...@dstar ~
$ cygcheck ./cmd.exe
-> D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe
cygcheck: could
Greetings, Christopher Faylor!
>>[snip...]
>>> a...@dstar ~
>>> $ ln -s `which cmd.exe` cmd.exe
>>>
>>> a...@dstar ~
>>> $ cygcheck ./cmd.exe
>>> -> D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe
>>> cygcheck: could not find './cmd.exe'
>>
>>cygcheck is not a cygwin application, it's a
On Wed, Oct 20, 2010 at 07:46:05PM -0400, Rolf Campbell wrote:
>On 2010-10-19 19:17, Arseny Slobodyuk wrote:
>[snip...]
>> a...@dstar ~
>> $ ln -s `which cmd.exe` cmd.exe
>>
>> a...@dstar ~
>> $ cygcheck ./cmd.exe
>> -> D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe
>> cygcheck: could no
On 2010-10-19 19:17, Arseny Slobodyuk wrote:
[snip...]
a...@dstar ~
$ ln -s `which cmd.exe` cmd.exe
a...@dstar ~
$ cygcheck ./cmd.exe
-> D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe
cygcheck: could not find './cmd.exe'
cygcheck is not a cygwin application, it's a native windows ap
On 10/25/2009 09:47 PM, Paul McFerrin wrote:
What gives. I see thru-out the source code reference to "fopen(a, ...,
"rt") but when I look at the various manual paes for fopen, I find
nothing about the "t". What is "t"? Any GURU want to answer?
The opposite of "rb". b = binary. t = text. Yes
Larry Hall (Cygwin) wrote:
On 10/25/2009 09:47 PM, Paul McFerrin wrote:
What gives. I see thru-out the source code reference to "fopen(a, ...,
"rt") but when I look at the various manual paes for fopen, I find
nothing about the "t". What is "t"? Any GURU want to answer?
The opposite of "rb"
What gives. I see thru-out the source code reference to "fopen(a, ...,
"rt") but when I look at the various manual paes for fopen, I find
nothing about the "t". What is "t"? Any GURU want to answer?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cyg
1 - 100 of 206 matches
Mail list logo
