Re: [PATCH 1/1] make `cygcheck --find-package` output parseable

[Christoph Anton Mitterer]

On Fri, 2024-05-24 at 17:24 +0100, Jon Turney wrote:
> 
> So, this isn't really true, per the rules [1].  However, there are
> some 
> historical exceptions [2], which ideally we'd remove or replace.

Well, I guess as long as they still exist, respectively as long as it's
technically possible to have such, there should be a proper way to
parse.

Looking at the git history of that file, it seems that these exceptions
exist since quite a while, so it doesn't seem as if they'd be going
away anytime soon.


> Even with those exceptions, I think the heuristic of (i) split PVR on
> the leftmost hyphen followed by a digit, to split P and VR, (ii) then
> split VR on the rightmost hyphen, to split V and R, always gives the 
> right answer.

Ideally one would have something that makes parsing as simply as using
cut -d Y -f X.
The current schema fails even with some already more complex regexp
like `s/^(.+)-(.+)-[9-9]$/.../` because .+ is greedy.

So as you said, it would need to take the surroundings of the '-' of
the current exceptions into account, making the rule even more ugly to
read.



> That's not to say something like this isn't a good idea, but I think
> it 
> would perhaps be better to have an option explicitly produce
> something 
> machine readable (as csv or whatever...)

Well, any output like CSV, JSON, etc. would already need again some
smarter parsing tool.


Cheers,
Chris.

Re: [PATCH 1/1] make `cygcheck --find-package` output parseable

[Jon Turney]

On 22/05/2024 01:35, Christoph Anton Mitterer wrote:

From: Christoph Anton Mitterer 


Thanks very much for this patch.


Both, package names and version numbers, are allowed to contain `-`, which makes
the output of `cygcheck --find-package` not parseable.


So, this isn't really true, per the rules [1].  However, there are some 
historical exceptions [2], which ideally we'd remove or replace.


Even with those exceptions, I think the heuristic of (i) split PVR on 
the leftmost hyphen followed by a digit, to split P and VR, (ii) then 
split VR on the rightmost hyphen, to split V and R, always gives the 
right answer.


[1] https://cygwin.com/packaging-package-files.html
[2] https://cygwin.com/cgit/cygwin-apps/calm/tree/calm/past_mistakes.py#n30


This changes the separator between package name and version to be a space, which
is not allowed in package names.


That's not to say something like this isn't a good idea, but I think it 
would perhaps be better to have an option explicitly produce something 
machine readable (as csv or whatever...)




Signed-off-by: Christoph Anton Mitterer 
---
  winsup/utils/mingw/dump_setup.cc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/utils/mingw/dump_setup.cc b/winsup/utils/mingw/dump_setup.cc
index 050679a0d..e30f0f8ed 100644
--- a/winsup/utils/mingw/dump_setup.cc
+++ b/winsup/utils/mingw/dump_setup.cc
@@ -590,7 +590,7 @@ package_find (int verbose, char **argv)
{
  if (verbose)
printf ("%s: found in package ", filename);
- printf ("%s-%s\n", packages[i].name, packages[i].ver);
+ printf ("%s %s\n", packages[i].name, packages[i].ver);
}
}
}

[PATCH 0/1] make `cygcheck --find-package` output parseable

[Christoph Anton Mitterer]

Hey.

Just a simple patch that should make the output of
`cygcheck --find-package` parseable.

It would however be a backwards incompatible change, OTOH it cannot
really see how much can be done with the current output format properly
in a machine-readable way – and humans probably won’t care about the
changed separator.

Cheers,
Chris.

[PATCH 1/1] make `cygcheck --find-package` output parseable

[Christoph Anton Mitterer]

From: Christoph Anton Mitterer 

Both, package names and version numbers, are allowed to contain `-`, which makes
the output of `cygcheck --find-package` not parseable.

This changes the separator between package name and version to be a space, which
is not allowed in package names.

Signed-off-by: Christoph Anton Mitterer 
---
 winsup/utils/mingw/dump_setup.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/utils/mingw/dump_setup.cc b/winsup/utils/mingw/dump_setup.cc
index 050679a0d..e30f0f8ed 100644
--- a/winsup/utils/mingw/dump_setup.cc
+++ b/winsup/utils/mingw/dump_setup.cc
@@ -590,7 +590,7 @@ package_find (int verbose, char **argv)
{
  if (verbose)
printf ("%s: found in package ", filename);
- printf ("%s-%s\n", packages[i].name, packages[i].ver);
+ printf ("%s %s\n", packages[i].name, packages[i].ver);
}
}
}
-- 
2.45.1

Re: [PATCH] Cygwin: Fix a stray '\n' in cygcheck manpage

[Corinna Vinschen]

On Jan 10 13:57, Jon Turney wrote:
> ---
>  winsup/doc/utils.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/winsup/doc/utils.xml b/winsup/doc/utils.xml
> index 8261e7ebd..692dae38f 100644
> --- a/winsup/doc/utils.xml
> +++ b/winsup/doc/utils.xml
> @@ -210,7 +210,7 @@ At least one command option or a PROGRAM is required, as 
> shown above.
> plain console only, not from a pty/rxvt/xterm)
>-e, --search-package list all available packages matching PATTERN
> PATTERN is a glob pattern with * and ? as wildcard 
> chars
> -  search selection specifiers (multiple allowed):\n\
> +  search selection specifiers (multiple allowed):
>--requires   list packages depending on packages matching PATTERN
>--build-reqs list packages depending on packages matching PATTERN
> when building these packages
> -- 
> 2.42.1

Yep, thanks!

[PATCH] Cygwin: Fix a stray '\n' in cygcheck manpage

[Jon Turney]

---
 winsup/doc/utils.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/doc/utils.xml b/winsup/doc/utils.xml
index 8261e7ebd..692dae38f 100644
--- a/winsup/doc/utils.xml
+++ b/winsup/doc/utils.xml
@@ -210,7 +210,7 @@ At least one command option or a PROGRAM is required, as 
shown above.
plain console only, not from a pty/rxvt/xterm)
   -e, --search-package list all available packages matching PATTERN
PATTERN is a glob pattern with * and ? as wildcard chars
-  search selection specifiers (multiple allowed):\n\
+  search selection specifiers (multiple allowed):
   --requires   list packages depending on packages matching PATTERN
   --build-reqs list packages depending on packages matching PATTERN
when building these packages
-- 
2.42.1

Re: [PATCH] Cygwin: Add '--names-only' flag to cygcheck

[Jon Turney]

On 24/11/2023 18:31, Corinna Vinschen wrote:

On Nov 24 17:06, Jon Turney wrote:

Add '--names-only' flag to cygcheck, to output just the bare package
names.


Push it!



I added changes to the manpage to document this option as well, before 
pushing it.


Thanks.

Re: [PATCH] Cygwin: Add '--names-only' flag to cygcheck

[Corinna Vinschen]

On Nov 24 17:06, Jon Turney wrote:
> Add '--names-only' flag to cygcheck, to output just the bare package
> names.

Push it!

> ---
> 
> Notes:
> Rather than more hacky aftermarket solutions, let's make cygcheck output
> something more useful for feeding into setup.
> 
> Next step would be to adjust setup's argument parsing so 'setup -P
> "$(cygcheck -n)"' works as expected.

Or cygcheck could just create a comma-separated list?  Either way is fine.


Thanks,
Corinna

[PATCH] Cygwin: Add '--names-only' flag to cygcheck

[Jon Turney]

Add '--names-only' flag to cygcheck, to output just the bare package
names.
---

Notes:
Rather than more hacky aftermarket solutions, let's make cygcheck output
something more useful for feeding into setup.

Next step would be to adjust setup's argument parsing so 'setup -P
"$(cygcheck -n)"' works as expected.

 winsup/utils/mingw/cygcheck.cc   | 18 +-
 winsup/utils/mingw/dump_setup.cc | 17 +++--
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/winsup/utils/mingw/cygcheck.cc b/winsup/utils/mingw/cygcheck.cc
index 9d6f19203..1dde2ecba 100644
--- a/winsup/utils/mingw/cygcheck.cc
+++ b/winsup/utils/mingw/cygcheck.cc
@@ -55,6 +55,7 @@ int givehelp = 0;
 int keycheck = 0;
 int check_setup = 0;
 int dump_only = 0;
+int names_only = 0;
 int find_package = 0;
 int list_package = 0;
 int grep_packages = 0;
@@ -84,7 +85,7 @@ typedef __int64 longlong;
 #endif
 
 /* In dump_setup.cc  */
-void dump_setup (int, char **, bool);
+void dump_setup (int, char **, bool, bool);
 void package_find (int, char **);
 void package_list (int, char **);
 /* In bloda.cc  */
@@ -2913,7 +2914,8 @@ At least one command option or a PROGRAM is required, as 
shown above.\n\
   PROGRAM  list library (DLL) dependencies of PROGRAM\n\
   -c, --check-setupshow installed version of PACKAGE and verify 
integrity\n\
(or for all installed packages if none specified)\n\
-  -d, --dump-only  just list packages, do not verify (with -c)\n\
+  -d, --dump-only  do not verify packages (with -c)\n\
+  -n, --names-only just list package names (implies -c -d)\n\
   -s, --sysinfoproduce diagnostic system information (implies -c)\n\
   -r, --registry   also scan registry for Cygwin settings (with -s)\n\
   -k, --keycheck   perform a keyboard check session (must be run from a\n\
@@ -2962,6 +2964,7 @@ Notes:\n\
 struct option longopts[] = {
   {"check-setup", no_argument, NULL, 'c'},
   {"dump-only", no_argument, NULL, 'd'},
+  {"names-only", no_argument, NULL, 'n'},
   {"sysinfo", no_argument, NULL, 's'},
   {"registry", no_argument, NULL, 'r'},
   {"verbose", no_argument, NULL, 'v'},
@@ -2985,7 +2988,7 @@ struct option longopts[] = {
   {0, no_argument, NULL, 0}
 };
 
-static char opts[] = "cdsrvkfliephV";
+static char opts[] = "cdnsrvkfliephV";
 
 static void
 print_version ()
@@ -3093,6 +3096,11 @@ main (int argc, char **argv)
   case 'd':
dump_only = 1;
break;
+  case 'n':
+   check_setup = 1;
+   dump_only = 1;
+   names_only = 1;
+   break;
   case 'r':
registry = 1;
break;
@@ -3205,7 +3213,7 @@ main (int argc, char **argv)
 }
 
   if (check_setup)
-dump_setup (verbose, argv, !dump_only);
+dump_setup (verbose, argv, !dump_only, names_only);
   else if (find_package)
 package_find (verbose, argv);
   else if (list_package)
@@ -3224,7 +3232,7 @@ main (int argc, char **argv)
   if (!check_setup)
{
  puts ("");
- dump_setup (verbose, NULL, !dump_only);
+ dump_setup (verbose, NULL, !dump_only, FALSE);
}
 
   if (!givehelp)
diff --git a/winsup/utils/mingw/dump_setup.cc b/winsup/utils/mingw/dump_setup.cc
index 06aa06f81..050679a0d 100644
--- a/winsup/utils/mingw/dump_setup.cc
+++ b/winsup/utils/mingw/dump_setup.cc
@@ -466,11 +466,13 @@ get_installed_packages (char **argv, size_t *count)
 }
 
 void
-dump_setup (int verbose, char **argv, bool check_files)
+dump_setup (int verbose, char **argv, bool check_files, bool names_only)
 {
   pkgver *packages = get_installed_packages (argv);
 
-  puts ("Cygwin Package Information");
+  if (!names_only)
+puts ("Cygwin Package Information");
+
   if (packages == NULL)
 {
   puts ("No setup information found");
@@ -484,12 +486,15 @@ dump_setup (int verbose, char **argv, bool check_files)
puts ("");
 }
 
-  printf ("%-*s %-*s%s\n", package_len, "Package",
-  check_files ? version_len : 7, "Version",
-  check_files ? " Status" : "");
+  if (!names_only)
+printf ("%-*s %-*s%s\n", package_len, "Package",
+   check_files ? version_len : 7, "Version",
+   check_files ? " Status" : "");
   for (int i = 0; packages[i].name; i++)
 {
-  if (check_files)
+  if (names_only)
+   printf ("%s\n", packages[i].name);
+  else if (check_files)
printf ("%-*s %-*s%s\n", package_len, packages[i].name,
version_len, packages[i].ver,
check_package_files (verbose, packages[i].name)
-- 
2.42.1

Re: [PATCH 0/7] cygcheck-dep updates

[⁠Mikhail Usenko via Cygwin-apps]

>Пятница, 27 октября 2023, 22:45 +03:00 от Brian Inglis via Cygwin-apps 
>:
> 
>Brian Inglis (7):
>   support better compressed setup.xz instead of bz2
>   fix no version for -C if only test release available
>   make cygcheck-dep executable
>   add /etc/{postinstall,preremove}/cygcheck-dep.sh
>   rename cygcheck-dep.sh to etc-preremove-cygcheck-dep.sh
>   add postinstall script to create cache dir
>   minimize cache dir preremove script
>
>  cygcheck-dep | 27 +++----
>  etc-postinstall-cygcheck-dep.sh | 1 +
>  etc-preremove-cygcheck-dep.sh | 1 +
>  3 files changed, 17 insertions(+), 12 deletions(-)
>  mode change 100644 => 100755 cygcheck-dep
>  create mode 100755 etc-postinstall-cygcheck-dep.sh
>  create mode 100755 etc-preremove-cygcheck-dep.sh
>
>--
>2.39.0
 
Brian, thank you for the cool solution to the issue when a package has only a 
test version!
 
--
 

[PATCH 0/7] cygcheck-dep updates

[Brian Inglis via Cygwin-apps]

Brian Inglis (7):
  support better compressed setup.xz instead of bz2
  fix no version for -C if only test release available
  make cygcheck-dep executable
  add /etc/{postinstall,preremove}/cygcheck-dep.sh
  rename cygcheck-dep.sh to etc-preremove-cygcheck-dep.sh
  add postinstall script to create cache dir
  minimize cache dir preremove script

 cygcheck-dep| 27 +++
 etc-postinstall-cygcheck-dep.sh |  1 +
 etc-preremove-cygcheck-dep.sh   |  1 +
 3 files changed, 17 insertions(+), 12 deletions(-)
 mode change 100644 => 100755 cygcheck-dep
 create mode 100755 etc-postinstall-cygcheck-dep.sh
 create mode 100755 etc-preremove-cygcheck-dep.sh

--
2.39.0
From e59d6fb3b4008536ee57865d64372a42a9c93277 Mon Sep 17 00:00:00 2001
Message-Id: 

In-Reply-To: 
References: 
From: Brian Inglis 
Date: Fri, 27 Oct 2023 13:25:20 -0600
Subject: [PATCH 1/7] support better compressed setup.xz instead of bz2

Signed-off-by: Brian Inglis 
---
 cygcheck-dep | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/cygcheck-dep b/cygcheck-dep
index 15c6be5a7193..72e345f80987 100644
--- a/cygcheck-dep
+++ b/cygcheck-dep
@@ -610,24 +610,24 @@ mach="${MACHTYPE%%-*}"
 ## download  file /*
 cw_setup_ini="$cache_dir/cygwin/$mach/setup.ini"
 if ! [ "$opt_use_cached_setup_ini" ] || [ "$cmd_show_updates" ]; then
-  cw_setup_bz2_url="ftp://sourceware.org/pub/cygwin/$mach/setup.bz2;
+  cw_setup_url="https://cygwin.com/pub/cygwin/$mach/setup.xz;
   [ "$opt_be_more_verbose" ] && opt_wget_verbosity="-nv" || 
opt_wget_verbosity="-q"
-  if ! wget >&2 "$opt_wget_verbosity" -r -nH --cut-dirs 1 -P "$cache_dir" 
"$cw_setup_bz2_url"; then
+  if ! wget >&2 "$opt_wget_verbosity" -r -nH --cut-dirs 1 -P "$cache_dir" 
"$cw_setup_url"; then
 echo >&2 "$0: failed to download  file:"
-echo >&2 "$0:   $cw_setup_bz2_url"
+echo >&2 "$0:   $cw_setup_url"
 echo >&2 "$0: you may try to run with -c option to use cached file from 
previous download"
 exit 4
   fi
-  cw_setup_bz2="$cache_dir/cygwin/$mach/setup.bz2"
-  if ! bzip2 -t "$cw_setup_bz2"; then
+  cw_setup="$cache_dir/cygwin/$mach/setup.xz"
+  if ! unxz -t "$cw_setup"; then
 echo >&2 "$0: failed to check integrity of downloaded  file:"
-echo >&2 "$0:   $cw_setup_bz2"
+echo >&2 "$0:   $cw_setup"
 echo >&2 "$0: you may try to run with -c option to use cached file from 
previous download"
 exit 5
   fi
-  if ! bzcat "$cw_setup_bz2" > "$cw_setup_ini"; then
+  if ! xzcat "$cw_setup" > "$cw_setup_ini"; then
 echo >&2 "$0: failed to decompress downloaded  file:"
-echo >&2 "$0:   $cw_setup_bz2"
+echo >&2 "$0:   $cw_setup"
 exit 6
   fi
 fi
-- 
2.39.0

From a349a1ddfc1c199bad04e59d7eb6c7fe7d4d2ff2 Mon Sep 17 00:00:00 2001
Message-Id: 

In-Reply-To: 
References: 
From: Brian Inglis 
Date: Fri, 27 Oct 2023 13:26:50 -0600
Subject: [PATCH 2/7] fix no version for -C if only test release available

Signed-off-by: Brian Inglis 
---
 cygcheck-dep | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/cygcheck-dep b/cygcheck-dep
index 72e345f80987..5b7fa4cda9d9 100644
--- a/cygcheck-dep
+++ b/cygcheck-dep
@@ -11,7 +11,7 @@
 ### DECLARATIONS
 
 name="cygcheck-dep"
-version="3.0"
+version="3.0-4"
 
 ## version(), help() /*
 
@@ -645,17 +645,20 @@ fi
 L=''; P=''; C=''; R=''; V=''; O=''; D=''; T=''
 
 ## read and parse  file; populate ${PkgID[]}, ${PkgName[]}, et al. 
/*
+# fix no version for -C if only test release available:
+# hold buffer => version seen: new package clears; version sets;
+# test label checks and cycles if no version, otherwise skips rest of package
 L="$(sed -n '
 :begin
-/^@\s\+\(\S\+\)\s*$/{s//add_new_package_to_catalogue "\1"/p; b}
+/^@\s\+\(\S\+\)\s*$/{s//add_new_package_to_catalogue "\1"/p; s/.*//; h; b}
 /^category:\s\+\(_obsolete\)\s*$/{s//PkgCategories[$MaxPkgID]="\1"; 
T="obsolete package"/p; b}
 /^category:\s\+\(\S\+\(\s\+\S\+\)*\)\s*$/{s//__make_list C "\1"; 
PkgCategories[$MaxPkgID]="$C"; T=''/p; b}
-/^version:\s\+\(\S\+\)\s*$/{s//PkgVersionAvailable[$MaxPkgID]="\1"/p; b}
+/^version:\s\+\(\S\+\)\s*$/{s//PkgVersionAvailable[$MaxPkgID]="\1"/p; h; b}
 /^obsoletes:\s\+\(\S\+\(\s\+\S\+\)*\)\s*$/{s//__make_list O "\1" ","; 
PkgObsoletedPkgs[$MaxPkgID]="$O"/p; b}
 /^requires:\s\+\(\S\+\(\s\+\S\+\)*\)\s*$/{s//[ "$T" ] \&\& { _

cygcheck: Missing file:

[Lee via Cygwin]

I just noticed this
  Missing file: /etc/preremove/openssl.sh from package libssl1.1
  Missing file: /etc/preremove/openssl.sh from package libssl3
in the output of 'cygcheck -srv'?

Is there something I should do about it?

TIA,
Lee

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

cygcheck-dep: handling of provides ?

[Marco Atzeri]

Hi Mikhail,

can you add the handling of provides ?


# /usr/bin/cygcheck-dep:
# warning: unknown package names:
#   the following encountered package names does not match
#   any available or installed package (use -M switch to get details):
#( perl5_032 gcc11)


$ grep "^provides:" setup.ini
provides: gcc11
provides: gcc10
provides: gcc11
provides: gfm15
provides: gfm15
provides: gfm15
provides: perl5_032
provides: perl5_030
provides: xserver-video-abi25
provides: xserver-video-abi25


It is a bit annoying to be forced to use continuosly "-q"

Thanks in advance
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: cygcheck doesn't work on DLLs and executables in current working directory

[Marco Atzeri via Cygwin]

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. Has anyone else experienced this?

Hamish




how are you calling it ?


$ cygcheck ./hello_c.exe
d:\cyg_pub\devel\openmpi\examples64\hello_c.exe
   D:\cygwin64\bin\cygwin1.dll
     C:\WINDOWS\system32\KERNEL32.dll
   C:\WINDOWS\system32\ntdll.dll
   C:\WINDOWS\system32\KERNELBASE.dll
   D:\cygwin64\bin\cygmpi-40.dll
     D:\cygwin64\bin\cygopen-pal-40.dll
   D:\cygwin64\bin\cygz.dll
   D:\cygwin64\bin\cyggcc_s-seh-1.dll
     D:\cygwin64\bin\cygopen-rte-40.dll
--
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


Irritatingly, I can't reproduce that now. It might well have been
something to do with my setup because VirtualBox is causing all sorts of
annoying problems at the moment. I'll reply again with output if it
happens again.

I did find something else though:

If I make a temporary directory and move into it, and then copy
/bin/bash and /bin/cygwin1.dll into it, if I run "cygcheck
/bin/bash.exe" it then says it depends on the cygwin1 DLL in the current
directory rather than the one in /bin:



that is expected. It is as Windows works

the shared libs in the same directory have precedence
on the one on the path.





--
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: cygcheck doesn't work on DLLs and executables in current working directory

[Hamish McIntyre-Bhatty via Cygwin]

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
>>
>>
>
> how are you calling it ?
>
>
> $ cygcheck ./hello_c.exe
> d:\cyg_pub\devel\openmpi\examples64\hello_c.exe
>   D:\cygwin64\bin\cygwin1.dll
>     C:\WINDOWS\system32\KERNEL32.dll
>   C:\WINDOWS\system32\ntdll.dll
>   C:\WINDOWS\system32\KERNELBASE.dll
>   D:\cygwin64\bin\cygmpi-40.dll
>     D:\cygwin64\bin\cygopen-pal-40.dll
>   D:\cygwin64\bin\cygz.dll
>   D:\cygwin64\bin\cyggcc_s-seh-1.dll
>     D:\cygwin64\bin\cygopen-rte-40.dll
> -- 
> 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

Irritatingly, I can't reproduce that now. It might well have been
something to do with my setup because VirtualBox is causing all sorts of
annoying problems at the moment. I'll reply again with output if it
happens again.

I did find something else though:

If I make a temporary directory and move into it, and then copy
/bin/bash and /bin/cygwin1.dll into it, if I run "cygcheck
/bin/bash.exe" it then says it depends on the cygwin1 DLL in the current
directory rather than the one in /bin:

Hamish@Hamish-PC ~
$ mkdir temp2

Hamish@Hamish-PC ~
$ cd temp2

Hamish@Hamish-PC ~/temp2
$ cp /bin/bash.exe /bin/cygwin1.dll ./

Hamish@Hamish-PC ~/temp2
$ cygcheck ./bash.exe
C:\cygwin64\home\Hamish\temp2\bash.exe
  C:\cygwin64\home\Hamish\temp2\cygwin1.dll
C:\WINDOWS\system32\KERNEL32.dll
  C:\WINDOWS\system32\ntdll.dll
  C:\WINDOWS\system32\KERNELBASE.dll
  C:\cygwin64\bin\cygiconv-2.dll
  C:\cygwin64\bin\cygintl-8.dll
  C:\cygwin64\bin\cygreadline7.dll
C:\cygwin64\bin\cygncursesw-10.dll

Hamish@Hamish-PC ~/temp2
$ cygcheck /bin/bash.exe
C:\cygwin64\bin\bash.exe
  C:\cygwin64\home\Hamish\temp2\cygwin1.dll
C:\WINDOWS\system32\KERNEL32.dll
  C:\WINDOWS\system32\ntdll.dll
  C:\WINDOWS\system32\KERNELBASE.dll
  C:\cygwin64\bin\cygiconv-2.dll
  C:\cygwin64\bin\cygintl-8.dll
  C:\cygwin64\bin\cygreadline7.dll
C:\cygwin64\bin\cygncursesw-10.dll

Not sure if this classes as a bug, rather than an interesting quirk with
the search path order (I guess), but perhaps worth mentioning.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
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: cygcheck doesn't work on DLLs and executables in current working directory

[Marco Atzeri via Cygwin]

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\openmpi\examples64\hello_c.exe
  D:\cygwin64\bin\cygwin1.dll
C:\WINDOWS\system32\KERNEL32.dll
  C:\WINDOWS\system32\ntdll.dll
  C:\WINDOWS\system32\KERNELBASE.dll
  D:\cygwin64\bin\cygmpi-40.dll
D:\cygwin64\bin\cygopen-pal-40.dll
  D:\cygwin64\bin\cygz.dll
  D:\cygwin64\bin\cyggcc_s-seh-1.dll
D:\cygwin64\bin\cygopen-rte-40.dll
--
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

cygcheck doesn't work on DLLs and executables in current working directory

[Hamish McIntyre-Bhatty via Cygwin]

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



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
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: cygcheck-dep: using depends2

[Mikhail Usenko]

On Mon, 31 Aug 2020 13:30:11 +0200
marco atzeri <...> wrote:

> On Mon, Aug 31, 2020 at 7:42 AM Mikhail Usenko  wrote:
> >
> > On Thu, 13 Aug 2020 16:01:54 +0200
> > Marco Atzeri via Cygwin-apps <...> wrote:
> >
> > > Hi Mikhail,
> > > can you please update cygcheck-dep to use "depends2:" field values
> > > instead of "requires:"
> > >
> > > It is not useful to see one library packages is needed by
> > > predecessors libraries:
> > >
> > > $ cygcheck-dep -q -S -N libMagickCore6_6
> > >   libMagickCore6_6: is recursively needed for ( a2ps asciidoc asymptote
> > > autotrace caja-extensions dblatex dmtx-utils feh gnome-common
> > > gnome-exe-thumbnailer gtk-doc html2ps ImageMagick inkscape karbon
> > > latex2rtf libautotrace-devel libautotrace3 libMagick-devel
> > > libMagickC++6_6 libMagickC++6_8 libMagickCore6_2 libMagickCore6_5
> > > libMagickCore6_6 libMagickWand6_2 libMagickWand6_5 libMagickWand6_6
> > > libpstoedit0 libWINGs-devel libWINGs3 libwraster-devel libwraster5
> > > libwraster6 mate-common perl-Image-Magick psiconv pstoedit
> > > pstoedit-devel WindowMaker xfce4-dev-tools xhtml2ps xmlto zbar )
> > >
> > > of course as there are multiples  "depends2:" only the current one
> > > should be used.
> > >
> >
> > Hello, Marco.
> > Sorry for the delay in response.
> > If it is to completely ignore the "requires:" field, the result is the very 
> > same:
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > $ ./cygcheck-dep -V
> > cygcheck-dep, version 3.1  # <--- modified testing version
> > $ ./cygcheck-dep -q -S -N libMagickCore6_6
> >  libMagickCore6_6: is recursively needed for ( autotrace dmtx-utils 
> > inkscape karbon libautotrace-devel libautotrace3 libMagickC++6_6 
> > libMagickC++6_8 libMagickCore6_2 libMagickCore6_5 libMagickCore6_6 
> > libMagickWand6_2 libMagickWand6_5 libMagickWand6_6 libpstoedit0 
> > libWINGs-devel libWINGs3 libwraster-devel libwraster5 libwraster6 psiconv 
> > pstoedit pstoedit-devel WindowMaker zbar )
> >
> > $ cygcheck-dep -V
> > cygcheck-dep, version 3.0  # <--- current version
> > $ cygcheck-dep -q -S -N libMagickCore6_6
> >  libMagickCore6_6: is recursively needed for ( autotrace dmtx-utils 
> > inkscape karbon libautotrace-devel libautotrace3 libMagickC++6_6 
> > libMagickC++6_8 libMagickCore6_2 libMagickCore6_5 libMagickCore6_6 
> > libMagickWand6_2 libMagickWand6_5 libMagickWand6_6 libpstoedit0 
> > libWINGs-devel libWINGs3 libwraster-devel libwraster5 libwraster6 psiconv 
> > pstoedit pstoedit-devel WindowMaker zbar )
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >
>
> Are you considering that there is a depends2 field for every version
> and you need to consider only
> the actual one ?
 
What do you mean by the "actual version"?
Setup.ini states that libMagickCore6_6 and libMagickCore6_5 are distinct 
separate packages, and
the current actual version of libMagickCore6_6 is 6.9.10.11-4 and previous ones 
are 6.9.10.11-2 and 6.9.10.11-1, and
the current actual version of libMagickCore6_5 is 6.9.9.11-3 and previous one 
is 6.9.9.11-1.
I am interpreting it this way, or is it not correct?


-- 

Re: cygcheck-dep: using depends2

[marco atzeri via Cygwin-apps]

On Mon, Aug 31, 2020 at 7:42 AM Mikhail Usenko  wrote:
>
> On Thu, 13 Aug 2020 16:01:54 +0200
> Marco Atzeri via Cygwin-apps <...> wrote:
>
> > Hi Mikhail,
> > can you please update cygcheck-dep to use "depends2:" field values
> > instead of "requires:"
> >
> > It is not useful to see one library packages is needed by
> > predecessors libraries:
> >
> > $ cygcheck-dep -q -S -N libMagickCore6_6
> >   libMagickCore6_6: is recursively needed for ( a2ps asciidoc asymptote
> > autotrace caja-extensions dblatex dmtx-utils feh gnome-common
> > gnome-exe-thumbnailer gtk-doc html2ps ImageMagick inkscape karbon
> > latex2rtf libautotrace-devel libautotrace3 libMagick-devel
> > libMagickC++6_6 libMagickC++6_8 libMagickCore6_2 libMagickCore6_5
> > libMagickCore6_6 libMagickWand6_2 libMagickWand6_5 libMagickWand6_6
> > libpstoedit0 libWINGs-devel libWINGs3 libwraster-devel libwraster5
> > libwraster6 mate-common perl-Image-Magick psiconv pstoedit
> > pstoedit-devel WindowMaker xfce4-dev-tools xhtml2ps xmlto zbar )
> >
> > of course as there are multiples  "depends2:" only the current one
> > should be used.
> >
>
> Hello, Marco.
> Sorry for the delay in response.
> If it is to completely ignore the "requires:" field, the result is the very 
> same:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> $ ./cygcheck-dep -V
> cygcheck-dep, version 3.1  # <--- modified testing version
> $ ./cygcheck-dep -q -S -N libMagickCore6_6
>  libMagickCore6_6: is recursively needed for ( autotrace dmtx-utils inkscape 
> karbon libautotrace-devel libautotrace3 libMagickC++6_6 libMagickC++6_8 
> libMagickCore6_2 libMagickCore6_5 libMagickCore6_6 libMagickWand6_2 
> libMagickWand6_5 libMagickWand6_6 libpstoedit0 libWINGs-devel libWINGs3 
> libwraster-devel libwraster5 libwraster6 psiconv pstoedit pstoedit-devel 
> WindowMaker zbar )
>
> $ cygcheck-dep -V
> cygcheck-dep, version 3.0  # <--- current version
> $ cygcheck-dep -q -S -N libMagickCore6_6
>  libMagickCore6_6: is recursively needed for ( autotrace dmtx-utils inkscape 
> karbon libautotrace-devel libautotrace3 libMagickC++6_6 libMagickC++6_8 
> libMagickCore6_2 libMagickCore6_5 libMagickCore6_6 libMagickWand6_2 
> libMagickWand6_5 libMagickWand6_6 libpstoedit0 libWINGs-devel libWINGs3 
> libwraster-devel libwraster5 libwraster6 psiconv pstoedit pstoedit-devel 
> WindowMaker zbar )
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
Hi Mikhail,
Are you considering that there is a depends2 field for every version
and you need to consider only
the actual one ?

Regards
Marco

Re: cygcheck-dep: using depends2

[Mikhail Usenko]

On Thu, 13 Aug 2020 16:01:54 +0200
Marco Atzeri via Cygwin-apps <...> wrote:

> Hi Mikhail,
> can you please update cygcheck-dep to use "depends2:" field values
> instead of "requires:"
> 
> It is not useful to see one library packages is needed by
> predecessors libraries:
> 
> $ cygcheck-dep -q -S -N libMagickCore6_6
>   libMagickCore6_6: is recursively needed for ( a2ps asciidoc asymptote 
> autotrace caja-extensions dblatex dmtx-utils feh gnome-common 
> gnome-exe-thumbnailer gtk-doc html2ps ImageMagick inkscape karbon 
> latex2rtf libautotrace-devel libautotrace3 libMagick-devel 
> libMagickC++6_6 libMagickC++6_8 libMagickCore6_2 libMagickCore6_5 
> libMagickCore6_6 libMagickWand6_2 libMagickWand6_5 libMagickWand6_6 
> libpstoedit0 libWINGs-devel libWINGs3 libwraster-devel libwraster5 
> libwraster6 mate-common perl-Image-Magick psiconv pstoedit 
> pstoedit-devel WindowMaker xfce4-dev-tools xhtml2ps xmlto zbar )
> 
> of course as there are multiples  "depends2:" only the current one 
> should be used.
> 

Hello, Marco.
Sorry for the delay in response.
If it is to completely ignore the "requires:" field, the result is the very 
same:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
$ ./cygcheck-dep -V
cygcheck-dep, version 3.1  # <--- modified testing version
$ ./cygcheck-dep -q -S -N libMagickCore6_6
 libMagickCore6_6: is recursively needed for ( autotrace dmtx-utils inkscape 
karbon libautotrace-devel libautotrace3 libMagickC++6_6 libMagickC++6_8 
libMagickCore6_2 libMagickCore6_5 libMagickCore6_6 libMagickWand6_2 
libMagickWand6_5 libMagickWand6_6 libpstoedit0 libWINGs-devel libWINGs3 
libwraster-devel libwraster5 libwraster6 psiconv pstoedit pstoedit-devel 
WindowMaker zbar )

$ cygcheck-dep -V
cygcheck-dep, version 3.0  # <--- current version
$ cygcheck-dep -q -S -N libMagickCore6_6
 libMagickCore6_6: is recursively needed for ( autotrace dmtx-utils inkscape 
karbon libautotrace-devel libautotrace3 libMagickC++6_6 libMagickC++6_8 
libMagickCore6_2 libMagickCore6_5 libMagickCore6_6 libMagickWand6_2 
libMagickWand6_5 libMagickWand6_6 libpstoedit0 libWINGs-devel libWINGs3 
libwraster-devel libwraster5 libwraster6 psiconv pstoedit pstoedit-devel 
WindowMaker zbar )
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


-- 

cygcheck-dep: using depends2

[Marco Atzeri via Cygwin-apps]

Hi Mikhail,
can you please update cygcheck-dep to use "depends2:" field values
instead of "requires:"

It is not useful to see one library packages is needed by
predecessors libraries:

$ cygcheck-dep -q -S -N libMagickCore6_6
 libMagickCore6_6: is recursively needed for ( a2ps asciidoc asymptote 
autotrace caja-extensions dblatex dmtx-utils feh gnome-common 
gnome-exe-thumbnailer gtk-doc html2ps ImageMagick inkscape karbon 
latex2rtf libautotrace-devel libautotrace3 libMagick-devel 
libMagickC++6_6 libMagickC++6_8 libMagickCore6_2 libMagickCore6_5 
libMagickCore6_6 libMagickWand6_2 libMagickWand6_5 libMagickWand6_6 
libpstoedit0 libWINGs-devel libWINGs3 libwraster-devel libwraster5 
libwraster6 mate-common perl-Image-Magick psiconv pstoedit 
pstoedit-devel WindowMaker xfce4-dev-tools xhtml2ps xmlto zbar )


of course as there are multiples  "depends2:" only the current one 
should be used.



Regards
Marco

Re: Cygwin package search and cygcheck -p urlencoding still broken on new web server

[Brian Inglis]

On 2020-07-16 07:42, Jon Turney wrote:
> On 16/07/2020 08:44, Marco Atzeri via Cygwin wrote:
>> On 16.07.2020 06:25, Brian Inglis wrote:
>>> On 2020-07-15 14:13, Marco Atzeri via Cygwin wrote:

> So it seems the urlencode is correct, but the urldecode isn't working.
> 
> I've applied a one-character change which appears to fix things.

>> the git logs says that only Frank and Jon have recently worked on
>>
>>     cgi-bin2/package-grep.cgi
>>
>> I would like to double check any possible modification before proposing a
>> patch to change the web server...

> This was actually fairly easy to reproduce locally, once I realized what was
> going on:
> 
> $ export url="libssh%2Flibssh.h" ; printf '%b' "${url//%/\x}"
> libsshx2Flibssh.h
> 
> $ export url="libssh%2Flibssh.h" ; printf '%b' "${ur//%/\\x}"
> libssh/libssh.h

Doh! Good catch! Been an annoyance for months.
I didn't realize cgi-bin scripts were visible under cygwin-htdocs/cgi-bin2.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
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: Cygwin package search and cygcheck -p urlencoding still broken on new web server

[Marco Atzeri via Cygwin]

On 16.07.2020 15:42, Jon Turney wrote:

On 16/07/2020 08:44, Marco Atzeri via Cygwin wrote:

On 16.07.2020 06:25, Brian Inglis wrote:

On 2020-07-15 14:13, Marco Atzeri via Cygwin wrote:

Problem: I want to search for
    libssh/libssh.h
Using https://cygwin.com/packages/
If I put the name and press Go the URL is changed in
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libssh%2Flibssh.h=x86_64 


and the output is
    Found 0 matches for libsshx2Flibssh.h
  ^^^
Instead if I modify directly the URL in:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libssh/libssh.h=x86_64 



I think that this is an invalid URL, that just happens to work, so it's 
correct that the link we produce is urlencoded.


(See e.g. https://en.wikipedia.org/wiki/Query_string#URL_encoding)


Found 3 matches for libssh/libssh.h

I guess that the current incapability is due to spurious urlencode in
cgi-bin2/package-grep.cgi
that is modifing the $param_grep
echo ''$file' - 
'$desc''

Could someone double check my guess ?


So it seems the urlencode is correct, but the urldecode isn't working.

I've applied a one-character change which appears to fix things.


the git logs says that only Frank and Jon have recently worked on

    cgi-bin2/package-grep.cgi

I would like to double check any possible modification before proposing a
patch to change the web server...


This was actually fairly easy to reproduce locally, once I realized what 
was going on:


$ export url="libssh%2Flibssh.h" ; printf '%b' "${url//%/\x}"
libsshx2Flibssh.h

$ export url="libssh%2Flibssh.h" ; printf '%b' "${ur//%/\\x}"
libssh/libssh.h


Thanks Jon

now the search works fine also with cygcheck -p

--
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: Cygwin package search and cygcheck -p urlencoding still broken on new web server

[Jon Turney]

On 16/07/2020 08:44, Marco Atzeri via Cygwin wrote:

On 16.07.2020 06:25, Brian Inglis wrote:

On 2020-07-15 14:13, Marco Atzeri via Cygwin wrote:

Problem: I want to search for
    libssh/libssh.h
Using https://cygwin.com/packages/
If I put the name and press Go the URL is changed in
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libssh%2Flibssh.h=x86_64 


and the output is
    Found 0 matches for libsshx2Flibssh.h
  ^^^
Instead if I modify directly the URL in:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libssh/libssh.h=x86_64 


I think that this is an invalid URL, that just happens to work, so it's 
correct that the link we produce is urlencoded.


(See e.g. https://en.wikipedia.org/wiki/Query_string#URL_encoding)


Found 3 matches for libssh/libssh.h

I guess that the current incapability is due to spurious urlencode in
cgi-bin2/package-grep.cgi
that is modifing the $param_grep
echo ''$file' - 
'$desc''

Could someone double check my guess ?


So it seems the urlencode is correct, but the urldecode isn't working.

I've applied a one-character change which appears to fix things.


the git logs says that only Frank and Jon have recently worked on

    cgi-bin2/package-grep.cgi

I would like to double check any possible modification before proposing a
patch to change the web server...


This was actually fairly easy to reproduce locally, once I realized what 
was going on:


$ export url="libssh%2Flibssh.h" ; printf '%b' "${url//%/\x}"
libsshx2Flibssh.h

$ export url="libssh%2Flibssh.h" ; printf '%b' "${ur//%/\\x}"
libssh/libssh.h
--
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: Cygwin package search and cygcheck -p urlencoding still broken on new web server

[Marco Atzeri via Cygwin]

On 16.07.2020 06:25, Brian Inglis wrote:

On 2020-07-15 14:13, Marco Atzeri via Cygwin wrote:

Problem: I want to search for
    libssh/libssh.h
Using https://cygwin.com/packages/
If I put the name and press Go the URL is changed in
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libssh%2Flibssh.h=x86_64
and the output is
    Found 0 matches for libsshx2Flibssh.h
  ^^^
Instead if I modify directly the URL in:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libssh/libssh.h=x86_64
Found 3 matches for libssh/libssh.h

I guess that the current incapability is due to spurious urlencode in
cgi-bin2/package-grep.cgi
that is modifing the $param_grep
echo ''$file' - '$desc''
Could someone double check my guess ?


No change since your report on May 2nd, and my cross-post to overseers:

https://cygwin.com/pipermail/cygwin/2020-May/244684.html

https://sourceware.org/pipermail/overseers/2020q2/017115.html

where Frank suggested replacing badly urlencoded characters by ".":


this works as the dot is not changed

case $c in
[a-zA-Z0-9.~_-]) printf "$c" ;;
*) printf '%%%02X' "'$c"


$ cygcheck -p libssh/libssh.h
Found 0 matches for libsshx2flibssh.h
$ cygcheck -p libssh.libssh.h
Found 3 matches for libssh.libssh.h
libssh-devel-0.7.3-1 - libssh-devel: SSH implementation library (installed
binaries and support files)
libssh-devel-0.7.5-1 - libssh-devel: SSH implementation library
libssh-devel-0.8.7-1 - libssh-devel: SSH implementation library

The previous break appears to have been fixed by or due to Achim:

https://cygwin.com/pipermail/cygwin/2019-November/243112.html

Ping Achim?!



the git logs says that only Frank and Jon have recently worked on

   cgi-bin2/package-grep.cgi

I would like to doble check any possible modification before proposing a
patch to change the web server...

Regards
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: Cygwin package search and cygcheck -p urlencoding still broken on new web server

[Brian Inglis]

On 2020-07-15 14:13, Marco Atzeri via Cygwin wrote:
> Problem: I want to search for
>    libssh/libssh.h
> Using https://cygwin.com/packages/
> If I put the name and press Go the URL is changed in
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libssh%2Flibssh.h=x86_64
> and the output is
>    Found 0 matches for libsshx2Flibssh.h
>  ^^^
> Instead if I modify directly the URL in:
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libssh/libssh.h=x86_64
> Found 3 matches for libssh/libssh.h
> 
> I guess that the current incapability is due to spurious urlencode in
> cgi-bin2/package-grep.cgi
> that is modifing the $param_grep
> echo ''$file' - '$desc''
> Could someone double check my guess ?

No change since your report on May 2nd, and my cross-post to overseers:

https://cygwin.com/pipermail/cygwin/2020-May/244684.html

https://sourceware.org/pipermail/overseers/2020q2/017115.html

where Frank suggested replacing badly urlencoded characters by ".":

$ cygcheck -p libssh/libssh.h
Found 0 matches for libsshx2flibssh.h
$ cygcheck -p libssh.libssh.h
Found 3 matches for libssh.libssh.h
libssh-devel-0.7.3-1 - libssh-devel: SSH implementation library (installed
binaries and support files)
libssh-devel-0.7.5-1 - libssh-devel: SSH implementation library
libssh-devel-0.8.7-1 - libssh-devel: SSH implementation library

The previous break appears to have been fixed by or due to Achim:

https://cygwin.com/pipermail/cygwin/2019-November/243112.html

Ping Achim?!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
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: changed behaviour for "cygcheck -p "

[Brian Inglis]

On 2020-05-02 09:36, Frank Ch. Eigler wrote:
>>> It seems there is a new escape system that is fooling
>>> the search engine
>>> $ cygcheck -p 'bin/mutt'
>> https://cygwin.com/packages/
> 
> I suspect it's not new, but yes, urlescaped %XY characters are not
> correctly handled in package-grep.cgi.  Until it's fixed, you can use
> dots instead of slashes, for example.

The issue is new since the new server, both cygcheck -p, and Cygwin Package
Search which it invokes at https://cygwin.com/packages/..., worked fine
previously, as the common specific search target was /usr/bin/...

Is the new RHEL/Fedora/CentOS system you are using missing url{en,de}code, or
the path to those, or something else invoked in package-grep.cgi?

Maybe update https://sourceware.org/lists.html#what-software to document recent
changes and https://sourceware.org/news.html to track issues and fixes.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
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: changed behaviour for "cygcheck -p "

[Marco Atzeri via Cygwin]

Am 02.05.2020 um 17:36 schrieb Frank Ch. Eigler via Cygwin:

Hi -


It seems there is a new escape system that is fooling
the search engine
$ cygcheck -p 'bin/mutt'

https://cygwin.com/packages/


I suspect it's not new, but yes, urlescaped %XY characters are not
correctly handled in package-grep.cgi.  Until it's fixed, you can use
dots instead of slashes, for example.

- FChE


Hi Frank,
it was working on the old server, so it is a new issue.

Regards
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: changed behaviour for "cygcheck -p "

[Frank Ch. Eigler via Cygwin]

Hi -

> > It seems there is a new escape system that is fooling
> > the search engine
> > $ cygcheck -p 'bin/mutt'
> https://cygwin.com/packages/

I suspect it's not new, but yes, urlescaped %XY characters are not
correctly handled in package-grep.cgi.  Until it's fixed, you can use
dots instead of slashes, for example.

- FChE
--
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: changed behaviour for "cygcheck -p "

[Brian Inglis]

On 2020-05-02 04:11, Marco Atzeri via Cygwin wrote:
> It seems there is a new escape system that is fooling
> the search engine
> 
> $ cygcheck -p 'bin/mutt'
> Found 0 matches for binx2fmutt
> 
> same on the Web

e.g. Cygwin Packag Search

https://cygwin.com/packages/

enter:

"...
[ bin/cpuid.exe ] [Go]

( ) x86 (o) x86_64
..."

https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin%2Fcpuid.exe=x86_64

result:

"...
Cygwin Package Search

Search package contents for a grep basic regular expression pattern

[ binx2Fcpuid.exe ] [Go]

( ) x86 (o) x86_64

Search Results

 Found 0 matches for x2Fusrx2Fbinx2Fcpuid.exe
"

but tweak the browser URL directly:

https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin/cpuid.exe=x86_64

"...
Cygwin Package Search

Search package contents for a grep basic regular expression pattern

[ bin/cpuid.exe ] [Go]

( ) x86 (o) x86_64

Search Results

 Found 2 matches for bin/cpuid.exe

cpuid-20200211-1 - cpuid: dumps CPUID information about the CPU(s)
cpuid-20200427-1 - cpuid: dumps CPUID information about the CPU(s)
"

and curl and wget also work with the above non-urlencoded URL, so it looks like
the new server CGI borks handling urlencoded parameter values e.g. / -> %2F,
from either cygcheck -p or the web form, possibly from trying to pass thru some
urldecode filter converting %2F -> \x2F -> /, but with inadequate escaping
\\x2F, quoting '\x2F', or format (perhaps needs 0x2F?) to pass thru enough
layers to get converted, resulting in just converting "\x" to "x".

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
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

changed behaviour for "cygcheck -p "

[Marco Atzeri via Cygwin]

It seems there is a new escape system that is fooling
the search engine

$ cygcheck -p 'bin/mutt'
Found 0 matches for binx2fmutt

same on the Web

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

[newlib-cygwin] cygcheck: expand common_apps list

[Yaakov Selkowitz]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=5c2a3661c1aeefb0591ce46e8ab3274f0c6d9112

commit 5c2a3661c1aeefb0591ce46e8ab3274f0c6d9112
Author: Yaakov Selkowitz 
Date:   Thu May 23 11:47:36 2019 -0400

cygcheck: expand common_apps list

An increasing number of tools are being included in Windows which have the
same names as those included in Cygwin packages.  Indicating which one is
first in PATH can be helpful in diagnosing behavioural discrepencies
between them.

Also, fix the alphabetization of ssh.

Diff:
---
 winsup/utils/cygcheck.cc | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/winsup/utils/cygcheck.cc b/winsup/utils/cygcheck.cc
index d5972c0..2cc25d9 100644
--- a/winsup/utils/cygcheck.cc
+++ b/winsup/utils/cygcheck.cc
@@ -99,28 +99,43 @@ static common_apps[] = {
   {"awk", 0},
   {"bash", 0},
   {"cat", 0},
+  {"certutil", 0},
+  {"clinfo", 0},
+  {"comp", 0},
+  {"convert", 0},
   {"cp", 0},
   {"cpp", 1},
   {"crontab", 0},
+  {"curl", 0},
+  {"expand", 0},
   {"find", 0},
+  {"ftp", 0},
   {"gcc", 0},
   {"gdb", 0},
   {"grep", 0},
+  {"hostname", 0},
   {"kill", 0},
+  {"klist", 0},
   {"ld", 0},
   {"ls", 0},
   {"make", 0},
   {"mv", 0},
+  {"nslookup", 0},
   {"patch", 0},
   {"perl", 0},
+  {"replace", 0},
   {"rm", 0},
   {"sed", 0},
-  {"ssh", 0},
   {"sh", 0},
+  {"shutdown", 0},
+  {"sort", 0},
+  {"ssh", 0},
   {"tar", 0},
   {"test", 0},
+  {"timeout", 0},
   {"vi", 0},
   {"vim", 0},
+  {"whoami", 0},
   {0, 0}
 };

Re: [PATCH v2] cygcheck: expand common_apps list

[Corinna Vinschen]

Hi Yaakov,

On Jun  3 18:19, Yaakov Selkowitz wrote:
> An increasing number of tools are being included in Windows which have the
> same names as those included in Cygwin packages.  Indicating which one is
> first in PATH can be helpful in diagnosing behavioural discrepencies
> between them.
> 
> Also, fix the alphabetization of ssh.

Sure, please push.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

[PATCH v2] cygcheck: expand common_apps list

[Yaakov Selkowitz]

An increasing number of tools are being included in Windows which have the
same names as those included in Cygwin packages.  Indicating which one is
first in PATH can be helpful in diagnosing behavioural discrepencies
between them.

Also, fix the alphabetization of ssh.
---
 winsup/utils/cygcheck.cc | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/winsup/utils/cygcheck.cc b/winsup/utils/cygcheck.cc
index d5972c0cf..2cc25d985 100644
--- a/winsup/utils/cygcheck.cc
+++ b/winsup/utils/cygcheck.cc
@@ -99,28 +99,43 @@ static common_apps[] = {
   {"awk", 0},
   {"bash", 0},
   {"cat", 0},
+  {"certutil", 0},
+  {"clinfo", 0},
+  {"comp", 0},
+  {"convert", 0},
   {"cp", 0},
   {"cpp", 1},
   {"crontab", 0},
+  {"curl", 0},
+  {"expand", 0},
   {"find", 0},
+  {"ftp", 0},
   {"gcc", 0},
   {"gdb", 0},
   {"grep", 0},
+  {"hostname", 0},
   {"kill", 0},
+  {"klist", 0},
   {"ld", 0},
   {"ls", 0},
   {"make", 0},
   {"mv", 0},
+  {"nslookup", 0},
   {"patch", 0},
   {"perl", 0},
+  {"replace", 0},
   {"rm", 0},
   {"sed", 0},
-  {"ssh", 0},
   {"sh", 0},
+  {"shutdown", 0},
+  {"sort", 0},
+  {"ssh", 0},
   {"tar", 0},
   {"test", 0},
+  {"timeout", 0},
   {"vi", 0},
   {"vim", 0},
+  {"whoami", 0},
   {0, 0}
 };
 
-- 
2.17.0

Re: [PATCH] cygcheck: expand common_apps list

[Brian Inglis]

On 2019-06-03 13:35, Corinna Vinschen wrote:
> On May 23 13:05, Yaakov Selkowitz wrote:
>> An increasing number of tools are being included in Windows which have the
>> same names as those included in Cygwin packages.  Indicating which one is
>> first in PATH can be helpful in diagnosing behavioural discrepencies
>> between them.
>> Also, fix the alphabetization of ssh.
> on second thought you don't have to wait for Brian's reply.  Just
> push this.  If Brian has some more input, you can easily add another
> patch, right?

Haven't upgraded or bounced anything since then. Maybe after next Tuesday.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: [PATCH] cygcheck: expand common_apps list

[Corinna Vinschen]

Hi Yaakov,

On May 23 13:05, Yaakov Selkowitz wrote:
> An increasing number of tools are being included in Windows which have the
> same names as those included in Cygwin packages.  Indicating which one is
> first in PATH can be helpful in diagnosing behavioural discrepencies
> between them.
> 
> Also, fix the alphabetization of ssh.

on second thought you don't have to wait for Brian's reply.  Just
push this.  If Brian has some more input, you can easily add another
patch, right?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: [PATCH] cygcheck: expand common_apps list

[Corinna Vinschen]

On May 27 00:50, Yaakov Selkowitz wrote:
> On Sun, 2019-05-26 at 00:49 -0600, Brian Inglis wrote:
> > To a degree, depends on installed Cygwin packages and Windows features, but 
> > I
> > also have in both Cygwin /{,{,usr/}s}bin and 
> > /Windows/{,System32{,/OpenSSH}/:
> > 
> > {"certutil", 0},
> > {"comp", 0},
> > {"ftp", 0},
> > {"scp", 0},
> > {"sftp", 0},
> > {"sftp-server", 0},
> > {"shutdown", 0},
> > {"ssh-add", 0},
> > {"ssh-agent", 0},
> > {"sshd", 0},
> > {"ssh-keygen", 0},
> > {"ssh-keyscan", 0},
> > 
> > from ls *.exe | sort in each set of dirs then join both.
> 
> I don't have /Windows/OpenSSH on my system.  Is it added to PATH when
> present?
> 
> --
> Yaakov

Brian?  Ping?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: [PATCH] cygcheck: expand common_apps list

[Yaakov Selkowitz]

On Sun, 2019-05-26 at 00:49 -0600, Brian Inglis wrote:
> To a degree, depends on installed Cygwin packages and Windows features, but I
> also have in both Cygwin /{,{,usr/}s}bin and /Windows/{,System32{,/OpenSSH}/:
> 
> {"certutil", 0},
> {"comp", 0},
> {"ftp", 0},
> {"scp", 0},
> {"sftp", 0},
> {"sftp-server", 0},
> {"shutdown", 0},
> {"ssh-add", 0},
> {"ssh-agent", 0},
> {"sshd", 0},
> {"ssh-keygen", 0},
> {"ssh-keyscan", 0},
> 
> from ls *.exe | sort in each set of dirs then join both.

I don't have /Windows/OpenSSH on my system.  Is it added to PATH when
present?

--
Yaakov

Re: [PATCH] cygcheck: expand common_apps list

[Brian Inglis]

To a degree, depends on installed Cygwin packages and Windows features, but I
also have in both Cygwin /{,{,usr/}s}bin and /Windows/{,System32{,/OpenSSH}/:

{"certutil", 0},
{"comp", 0},
{"ftp", 0},
{"scp", 0},
{"sftp", 0},
{"sftp-server", 0},
{"shutdown", 0},
{"ssh-add", 0},
{"ssh-agent", 0},
{"sshd", 0},
{"ssh-keygen", 0},
{"ssh-keyscan", 0},

from ls *.exe | sort in each set of dirs then join both.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

[PATCH] cygcheck: expand common_apps list

[Yaakov Selkowitz]

An increasing number of tools are being included in Windows which have the
same names as those included in Cygwin packages.  Indicating which one is
first in PATH can be helpful in diagnosing behavioural discrepencies
between them.

Also, fix the alphabetization of ssh.
---
 winsup/utils/cygcheck.cc | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/winsup/utils/cygcheck.cc b/winsup/utils/cygcheck.cc
index d5972c0cf..0432f4a4d 100644
--- a/winsup/utils/cygcheck.cc
+++ b/winsup/utils/cygcheck.cc
@@ -99,28 +99,39 @@ static common_apps[] = {
   {"awk", 0},
   {"bash", 0},
   {"cat", 0},
+  {"clinfo", 0},
+  {"convert", 0},
   {"cp", 0},
   {"cpp", 1},
   {"crontab", 0},
+  {"curl", 0},
+  {"expand", 0},
   {"find", 0},
   {"gcc", 0},
   {"gdb", 0},
   {"grep", 0},
+  {"hostname", 0},
   {"kill", 0},
+  {"klist", 0},
   {"ld", 0},
   {"ls", 0},
   {"make", 0},
   {"mv", 0},
+  {"nslookup", 0},
   {"patch", 0},
   {"perl", 0},
+  {"replace", 0},
   {"rm", 0},
   {"sed", 0},
-  {"ssh", 0},
   {"sh", 0},
+  {"sort", 0},
+  {"ssh", 0},
   {"tar", 0},
   {"test", 0},
+  {"timeout", 0},
   {"vi", 0},
   {"vim", 0},
+  {"whoami", 0},
   {0, 0}
 };
 
-- 
2.17.0

Re: lib missing, cygcheck says "ok"?

[L A Walsh]

Thanks,  *sigh*.  Unfortunately, that also implies that no one
is using pulseaudio ?



On 11/3/2018 12:26 AM, Marco Atzeri wrote:

Well this is odd:   'cygcheck -c libspeexdsp1'

libspeexdsp1 1.2-0.1.rc3 OK

 cygcheck -l libspeexdsp1
 #nothing listed.


Did a reinstall on package and now -l lists the cygspeexdsp-1.dll file.

Why would cygcheck -c claim status "ok" when a file was missing?


 cygcheck --version

cygcheck (cygwin) 2.11.1


I see the same anomaly in one of my 2 installations.
My guess is that the package libspeexdsp1 was wrongly uploaded
and later corrected, without the needed version bump.


-

Thanks,  *sigh*.  Unfortunately, that also implies that no one
is using pulseaudio ?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: lib missing, cygcheck says "ok"?

[Marco Atzeri]

Am 02.11.2018 um 23:39 schrieb L A Walsh:

 cygcheck pulseaudio


cygcheck: track_down: could not find cygspeexdsp-1.dll

When I reinstalled the package, it didn't want any extra
packages.

I made sure the speex package was loaded, but that didn't have
it either.

Well this is odd:


 cygcheck -c libspeexdsp1

Cygwin Package Information
Package  Version Status
libspeexdsp1 1.2-0.1.rc3 OK

 cygcheck -l libspeexdsp1
 #nothing listed.


Did a reinstall on package and now -l lists the cygspeexdsp-1.dll file.

Why would cygcheck -c claim status "ok" when a file was missing?


 cygcheck --version

cygcheck (cygwin) 2.11.1




I see the same anomaly in one of my 2 installations.
My guess is that the package libspeexdsp1 was wrongly uploaded
and later corrected, without the needed version bump.









---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

lib missing, cygcheck says "ok"?

[L A Walsh]

 cygcheck pulseaudio


cygcheck: track_down: could not find cygspeexdsp-1.dll

When I reinstalled the package, it didn't want any extra
packages.

I made sure the speex package was loaded, but that didn't have
it either.

Well this is odd:


 cygcheck -c libspeexdsp1

Cygwin Package Information
Package  Version Status
libspeexdsp1 1.2-0.1.rc3 OK

 cygcheck -l libspeexdsp1
 #nothing listed.


Did a reinstall on package and now -l lists the cygspeexdsp-1.dll file.

Why would cygcheck -c claim status "ok" when a file was missing?


 cygcheck --version

cygcheck (cygwin) 2.11.1



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[newlib-cygwin] Cygwin: utils: cygcheck: fix filesystem output format

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=13909bc262b8de1b3a8f9d0662f9a6243482885c

commit 13909bc262b8de1b3a8f9d0662f9a6243482885c
Author: Corinna Vinschen 
Date:   Wed Aug 8 09:24:23 2018 +0200

Cygwin: utils: cygcheck: fix filesystem output format

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/utils/cygcheck.cc | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/winsup/utils/cygcheck.cc b/winsup/utils/cygcheck.cc
index 2d5cda3..d5972c0 100644
--- a/winsup/utils/cygcheck.cc
+++ b/winsup/utils/cygcheck.cc
@@ -1795,17 +1795,13 @@ dump_sysinfo ()
printf ("%7dMb %3d%% ", (int) capacity_mb, (int) percent_full);
   else
printf ("N/AN/A ");
-  printf ("%s %s %s %s %s %s  %s\n",
+  printf ("%s %s %s %s %s %s %s  %s\n",
  flags & FS_CASE_IS_PRESERVED ? "CP" : "  ",
  flags & FS_CASE_SENSITIVE ? "CS" : "  ",
  flags & FS_UNICODE_STORED_ON_DISK ? "UN" : "  ",
  flags & FS_PERSISTENT_ACLS ? "PA" : "  ",
  flags & FS_FILE_COMPRESSION ? "FC" : "  ",
  flags & FS_VOL_IS_COMPRESSED ? "VC" : "  ",
- flags & FILE_SUPPORTS_ENCRYPTION ? "EN" : "  ",
- flags & FILE_SUPPORTS_OBJECT_IDS ? "OI" : "  ",
- flags & FILE_SUPPORTS_REPARSE_POINTS ? "RP" : "  ",
- flags & FILE_SUPPORTS_SPARSE_FILES ? "SP" : "  ",
  flags & FILE_VOLUME_QUOTAS ? "QU" : "  ",
  name);
 }

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[Andrey Repin]

Greetings, L A Walsh!

>>> To start with, I need to hook up a PS/2 kbd & mouse
>>> to access those, while I could load the megaraid drivers
>>> then,
>> 
>> Or rebuild the Win7 disk image with related drivers.
>> Been doing that for years myself, but YMMV.
> ---
> Need to learn how...just have been more busy
> w/other stuff.  But w/new machine, it's vital.

> Trying to look at 'dism' to mount old .wim image
> and update it with needed drivers, using 
> https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-and-remove-drivers-to-an-offline-windows-image
> as a ref
> will have to see how that goes...

Indeed. the worst possible way - the MS official one :/

> If I have any probs, maybe can get back to you?

I've always used nLite to embed drivers and create unattended installation
disks.
https://www.nliteos.com/ or his new project https://www.ntlite.com/


-- 
With best regards,
Andrey Repin
Friday, May 25, 2018 17:23:31

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[L A Walsh]

Andrey Repin wrote:



To start with, I need to hook up a PS/2 kbd & mouse
to access those, while I could load the megaraid drivers
then,


Or rebuild the Win7 disk image with related drivers.
Been doing that for years myself, but YMMV.

---
Need to learn how...just have been more busy
w/other stuff.  But w/new machine, it's vital.

Trying to look at 'dism' to mount old .wim image
and update it with needed drivers, using 
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-and-remove-drivers-to-an-offline-windows-image

as a ref
will have to see how that goes...

If I have any probs, maybe can get back to you?

Tnx!
-linda

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[Andrey Repin]

Greetings, L A Walsh!

> David Conrad wrote:
>> I think Michel LaBarre's suggestion of running chkdsk and sfc is a
>> good one; 
> ---
> I agree...chkdsk indicated something odd in an attribute block,
> but I've yet to be able to correct it, since I'm running win7
> on a newer machine that uses USB3 and doesn't understand
> that my RAID controller is a megaraid type.

> So booting into recovery options (or booting from the win7
> install disk) both don't see any USB keyboard/mice
> nor the system-disk which uses the megaraid controller
> it just doesn't know it enough to see it...

> To start with, I need to hook up a PS/2 kbd & mouse
> to access those, while I could load the megaraid drivers
> then,

Or rebuild the Win7 disk image with related drivers.
Been doing that for years myself, but YMMV.

> it won't go through the discover process until
> the next reboot, at which point the megaraid drivers 
> will be gone again...so...working on updating my
> WinRE image and burning a new Win7 install disk that
> can understand the missing stuff.

> This is normal for me -- can't get from point 1 to 2
> without going through 3-4, where you need 5-6 as
> prereqs for those...etc...
> :-(


-- 
With best regards,
Andrey Repin
Wednesday, May 23, 2018 22:55:06

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[L A Walsh]

Michel LaBarre wrote:

If you need a boot environment that knows your hardware, try downloading the 
backup program Reflect from Macrium - there is a free version.



Wouldn't it be more prudent in the long run to make sure the repair-environment
builtin to windows and your install disk knows about the new HW?

I've had problems relying on 3rd party tools that I had trouble getting
to work some number of years later.

I'm able to backup the machine with the ms-backup tools, (crappy though they 
are),
and have those tools create an image backup every week.

I don't keep "data" on my winbox.  just on my linux box.
I try to only put programs on the winbox as I haven't found windows
to be very reliable over the long term.

Had system restore wipe files more than onceno fun.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[Michel LaBarre]

If you need a boot environment that knows your hardware, try downloading the 
backup program Reflect from Macrium - there is a free version.
(I use it for backup/recovery of my Win 10 and Win 7 systems.  So far it has 
been 100% solid.)

You can then use it to build a boot USB with all your drivers. 
I have not explored their recovery environment except to initiate a full system 
drive restore but at minimum, I expect it will include all the Windows 
facilities.

As an incidental bonus, you can create backups in case your remediation 
measures go south - restore and try again.  You can repeat steps 3-4 until you 
get it right... ;-)

Michel

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of L A Walsh
> Sent: May 21, 2018 2:28 PM
> To: cygwin@cygwin.com
> Subject: Re: normal to blue-screen windows when doing 'ls -CF' of
> /proc/sys/GLOBAL?? (bug? cygcheck attached)
> 
> David Conrad wrote:
> > I think Michel LaBarre's suggestion of running chkdsk and sfc is a
> > good one;
> ---
> I agree...chkdsk indicated something odd in an attribute block,
> but I've yet to be able to correct it, since I'm running win7
> on a newer machine that uses USB3 and doesn't understand
> that my RAID controller is a megaraid type.
> 
> So booting into recovery options (or booting from the win7
> install disk) both don't see any USB keyboard/mice
> nor the system-disk which uses the megaraid controller
> it just doesn't know it enough to see it...
> 
> To start with, I need to hook up a PS/2 kbd & mouse
> to access those, while I could load the megaraid drivers
> then, it won't go through the discover process until
> the next reboot, at which point the megaraid drivers
> will be gone again...so...working on updating my
> WinRE image and burning a new Win7 install disk that
> can understand the missing stuff.
> 
> This is normal for me -- can't get from point 1 to 2
> without going through 3-4, where you need 5-6 as
> prereqs for those...etc...
> :-(
> 
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[L A Walsh]

David Conrad wrote:

I think Michel LaBarre's suggestion of running chkdsk and sfc is a
good one; 

---
I agree...chkdsk indicated something odd in an attribute block,
but I've yet to be able to correct it, since I'm running win7
on a newer machine that uses USB3 and doesn't understand
that my RAID controller is a megaraid type.

So booting into recovery options (or booting from the win7
install disk) both don't see any USB keyboard/mice
nor the system-disk which uses the megaraid controller
it just doesn't know it enough to see it...

To start with, I need to hook up a PS/2 kbd & mouse
to access those, while I could load the megaraid drivers
then, it won't go through the discover process until
the next reboot, at which point the megaraid drivers 
will be gone again...so...working on updating my

WinRE image and burning a new Win7 install disk that
can understand the missing stuff.

This is normal for me -- can't get from point 1 to 2
without going through 3-4, where you need 5-6 as
prereqs for those...etc...
:-(


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[David Conrad]

On Thu, May 17, 2018 at 01:54 PM, L A Walsh  wrote:
> Very wierd.  It triggers so fast, and whatever is causing it, likely
> happens on a probe by 'ls' before ls even displays any output.
>
> I 'can' go into the same directory and do a "echo *" (or better,
> printf "%s\n" *  --- and that doesn't trigger it.
>
> I think I also triggered it once with 'tree'.  Very annoying.
>

You could try writing a small C program that does a readdir of that
directory and lstat of each file in it, logging what it's about to do
before each step. That would let you narrow down which entry is
triggering it, if that is indeed the cause.

I think Michel LaBarre's suggestion of running chkdsk and sfc is a
good one; strace also might help.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[L A Walsh]

Michel LaBarre wrote:

L A Walsh,

Please forgive the following naïve points but since I saw no mention of the 
easy checks...

Did you do a "chkdsk" and "sfc /scannow" at any point to pare out any obvious 
corruptions?


I have done chkdsk and sfc's in the past and both have been
clean.  Note -- this problem existed on the old computer as well (i.e.
before moving the system image).

I did an sfc yesturday and it found some uncorrectable probs -- haven't
checked specifics, but it's usually complaining because I have edited some
of the admin-utuil tools more to my liking -- and they get stored back
into the OS-files area, so it complains about that.

I'm running on a RAID10 of SSD's, while disk corruption isn't
out of the question, it seems unlikely.  Only time I experienced 
disc corruption in the past 15+ years has been some lost-extents that

were restored to a tmp area then deleted.



No messages in windows App or system log?

---
Ha!  0.  Of ANY kind.  Another long term prob that MS wasn't
able to solve.  My event service won't start.  Something reported to MS
forums about 3-4 years ago.  No one was able to solve it, and I wasn't
the only one with the problem.  Eventually people were told to upgrade
to Windows 10 in order to fix it:

Error 4201: The instance name passed was not recognized
as valid by a WMI data provider.




Does anything else behave out of the ordinary?

---
	I performed a reinstall/upgrade in place that supposed 
resets system files to their original state.  Sigh.





Since your environment is suspect (given you moved a disk from another machine I believe) and Cygwin/win7 are not, why not rebuild and re-install?  


Re build?  re-install?  Are you talking the inplace option or
a reformat otion?...the later would be a huge pain, as I already have software
that has stopped working that the company no longer supports giving you
replacement licenses for (Adobe).  They only support you "upgrading to the
cloud" and paying to rent...whereas the SW I have would work fine if they
hadn't build in a timebomb in the form of DRM that eventually won't renew.

If an individual did that, they'd go to prison, but if a corporation
does that, its considered good company management (Adobe's profits have gone up
by some huge amount when they went to subscription model). -- Of course they are
no longer doing much development -- no need to come up with new stuff
to attract upgrades...  Which is why MS went to subscription and ads for 
supporting
Win10 -- to get you out of the ownership habit.



Re-installation would give you assurance going forward that no surprise is 
about to upset some schedule due to a different less innocuous failure.


It's the re-install of over 300 applications with varying licensing
procedures (if they still exist at all) and various sources that is the hardest
part.



Cheers,
Michel 
  (AKA "someone" - I replied to you directly L A Walsh because I assumed many would find no problem as with me resulting in lots of SPAM in the mailing list

   FTHOI I tried it on a Win 7 box and it worked ok as in my Win 10 systems


---
Ah...didn't presume to know why, I just decided to not a
assume anything...

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[Michel LaBarre]

L A Walsh,

Please forgive the following naïve points but since I saw no mention of the 
easy checks...

Did you do a "chkdsk" and "sfc /scannow" at any point to pare out any obvious 
corruptions?
(When you chkdsk on C:, you will be asked if you want to do it on reboot since 
the disk must be offline.)

No messages in windows App or system log?

Does anything else behave out of the ordinary?

Since your environment is suspect (given you moved a disk from another machine 
I believe) and Cygwin/win7 are not, why not rebuild and re-install?  
Re-installation would give you assurance going forward that no surprise is 
about to upset some schedule due to a different less innocuous failure.

Cheers,
Michel 
  (AKA "someone" - I replied to you directly L A Walsh because I assumed many 
would find no problem as with me resulting in lots of SPAM in the mailing list
   FTHOI I tried it on a Win 7 box and it worked ok as in my Win 10 systems
  uname -a
  YGWIN_NT-6.1 dell 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin
)





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[L A Walsh]

Brian Inglis wrote:

Run "cygcheck ls" to see if any Windows installs added to your path pick up
api-ms-win-core-... intercept dlls e.g. Firefox, Tortoise, etc.

---
Nope. I set my path in my login profile:
reorder path, filter out dups and empty dirs and
use abbreviated paths for some common names.and filter out weird things in my
login profile.



Tried running same command under strace?
BLODA possibly messing up net access to AD?

---
Not running AD...using older NT4-style Dom on my home
lnx box.

Doubt it is BLODA, though not impossible given the growing number
if things that are incompat w/something.

BTW, is Win10 on the BLODA list?  seems to cause
alot of new incompats w/every release.

though in the same vein, MS updates for win7 seem to be
more likely to create problems as much as solve them since
they started trying to get people to switch away from pre-win10
OS's.  


Even had MS-forum-support people tell me that the fix for
some issue or another that they couldn't solve or fix 
was to move to Win10 (not that it was known to fix the 
problem -- just as a shotgun approach).



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[Brian Inglis]

On 2018-05-17 02:54, L A Walsh wrote:
> Andrey Repin wrote:
>> After BSOD, there should be at least aminibump.
>> You can use http://nirsoft.net/utils/blue_screen_view.html to examine it.
> 
> Tried it...showed nothing.  Checked sysprops and the small memory dump 
> (256KB)
> is enabled -- should have dumped in C:\windows\Minidump, but nothing was
> there.
> 
> I did try to see the module when the blue screen was up, but
> it rebooted too quickly.
> 
>> Do you perhaps have some misbehaving drivers in your system?
>> Try clearing up your device manager.
>>
>> SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 && mmc.exe devmgmt.msc
> ---
> Didn't see anything that stood out, but took the opportunity to remove all
> the ones that didn't refer to existing HW.
> 
> FWIW --- It almost has to be some misconfigured SW -- not any specific
> HW, since this windows image did the same thing on my last system.
> 
> I had to get a new system and moved over the hard disk - updated needed
> drives and I was up (about 4-5 months ago).
> 
> Very wierd.  It triggers so fast, and whatever is causing it, likely
> happens on a probe by 'ls' before ls even displays any output.
> 
> I 'can' go into the same directory and do a "echo *" (or better,
> printf "%s\n" *  --- and that doesn't trigger it.
> 
> I think I also triggered it once with 'tree'.  Very annoying.
> 
> Oh well, I suspected it wouldn't be simple, which is why I just try to
> "not do that"...but it had been a while, and thought maybe...
> 
> *grumble*
> 
> thanks for the ideas all...

Run "cygcheck ls" to see if any Windows installs added to your path pick up
api-ms-win-core-... intercept dlls e.g. Firefox, Tortoise, etc.
Tried running same command under strace?
BLODA possibly messing up net access to AD?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[L A Walsh]

Andrey Repin wrote:

After BSOD, there should be at least aminibump.
You can use http://nirsoft.net/utils/blue_screen_view.html to examine it.


Tried it...showed nothing.  Checked sysprops and the small memory dump 
(256KB)
is enabled -- should have dumped in C:\windows\Minidump, but nothing was
there.

I did try to see the module when the blue screen was up, but
it rebooted too quickly.



Do you perhaps have some misbehaving drivers in your system?
Try clearing up your device manager.

SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 && mmc.exe devmgmt.msc

---
	Didn't see anything that stood out, but took the opportunity 
to remove all the ones that didn't refer to existing HW.


FWIW --- It almost has to be some misconfigured SW -- not any specific
HW, since this windows image did the same thing on my last system.

I had to get a new system and moved over the hard disk - updated needed
drives and I was up (about 4-5 months ago).

Very wierd.  It triggers so fast, and whatever is causing it, likely
happens on a probe by 'ls' before ls even displays any output.

I 'can' go into the same directory and do a "echo *" (or better,
printf "%s\n" *  --- and that doesn't trigger it.

I think I also triggered it once with 'tree'.  Very annoying.

Oh well, I suspected it wouldn't be simple, which is why I just try to
"not do that"...but it had been a while, and thought maybe...

*grumble*

thanks for the ideas all...

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[Andrey Repin]

Greetings, L A Walsh!

> It didn't used to do this (a long time ago)...but has for about the
> past couple of years.

> Running on:
> CYGWIN_NT-6.1 Athenae 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin

> Win7SP1x64.

> If I do an 'ls -CF', as a "normal user" no admin privs (did a dropmyrights
> and verified that I only had traversal priv), of /proc/sys/Global\?\?/,
> it will blue screen my system every time.

After BSOD, there should be at least aminibump.
You can use http://nirsoft.net/utils/blue_screen_view.html to examine it.

> I didn't really want to even look for it, but finally decided to
> try it as an unprivileged user -- to see if that was an issue.

It was slow, but produced the list all right.

Win7Pro/RUS 64-bit.

Do you perhaps have some misbehaving drivers in your system?
Try clearing up your device manager.

SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 && mmc.exe devmgmt.msc


-- 
With best regards,
Andrey Repin
Wednesday, May 16, 2018 18:23:15

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[L A Walsh]

Someone else wrote:

Hi,
  just tried that command. There is no BSOD on my system. Windows 10
latest build, Dell laptop with latest Cygwin.
Maybe there is an issue with your anti-virus or application firewall?


---
(same Disclaimer -- replying to list on email sent to me
privately...  I would have a preference for people replying to both
list and me, unless they don't want to reply publicly, the private is
fine, though my *default*, (unless asked otherwise) will be to reply
publicly with personal info deleted)


I don't have *much* of an anti-virus and my system's on an internal
network (connected via proxy or sometimes NAT for games).  For malware
I just use the free MS "home essentials" which I usually (including now)
don't have set for real-time scanning -- I do a weekly scan
which takes several hours.

If it isn't set for real-time detection, though, I don't think
it would be causing an issue. No?

This is something that has persisted through many versions (like
more than a year or two), including things like repairing the OS via
an inplace "upgrade"/reinstall.  So it's fairly persistent (and annoying, 
as I used to like to look around in all the proc dirs).


-l



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[James Darnley]

On 2018-05-15 18:22, L A Walsh wrote:
> Someone wrote:
>> I tried it for the hell of it. It worked ok for me. 
>> Running windows 10 - build 1803 -
>>
>> $ uname -a
>> CYGWIN_NT-10.0 spiro1 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin
>>
>> Running as an normal user - I did not try an admin acct.
>>
>> Good luck, someone
> 
> (FYI -- replying to this "on-list", but anonymizing the sender's
> info in case they didn't want it posted.)
> 
> I wonder if it is Win7 specific or a quirk in my system.
> Too often it is some peculiarity in my system.
> 
> Thanks for the data point.

Here's another one: works4me on my Windows 7.
> CYGWIN_NT-6.1 Bahamut 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin

No BSOD when running that in my home directory.

I was lead to believe that no userland code could trigger BSODs anymore
so I don't think that is normal.  But maybe that is was only for 8+.
Next time you feel like triggering one read what "module" the fault was
in.  Last time I got one (caused by OC instability) I think it was in
ntfs.sys.



signature.asc
Description: OpenPGP digital signature

Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)

[L A Walsh]

Someone wrote:
I tried it for the hell of it. It worked ok for me.  


Running windows 10 - build 1803 -

$ uname -a
CYGWIN_NT-10.0 spiro1 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin

Running as an normal user - I did not try an admin acct.

Good luck, 
someone


	(FYI -- replying to this "on-list", but anonymizing the 
sender's info in case they didn't want it posted.)


I wonder if it is Win7 specific or a quirk in my system.
Too often it is some peculiarity in my system.

Thanks for the data point.





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] cygcheck-dep-3.0-2

[Mikhail Usenko via cygwin]

Version 3.0-2 of cygcheck-dep has been uploaded.

cygcheck-dep is a bash script for displaying information on dependencies
for installed Cygwin packages. For example: the information about package
leaves; packages with broken dependencies; obsolete, and orphaned packages;
particular package's dependencies; unused dependencies that can be removed
along with particular package meant for uninstalling. See --help for more
description.

It can be useful if you are using some Cygwin software, and want to
keep the Cygwin installation directory clean from unused packages.


Changelog since version 2.1-1:
  * the script is almost completely rewritten to reflect the changes
in setup.exe functioning and for clean code;
  * the legacy code for support of Cygwin Ports collection is dropped;
  * there are new command options.

--

   *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

 If you want to unsubscribe from the cygwin-announce mailing list,
 look at the "List-Unsubscribe: " tag in the email header of this message.
 Send email to the address specified there. It will be in the format:

   cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

 If you need more information on unsubscribing, start reading here:

   http://sourceware.org/lists.html#unsubscribe-simple

 Please read *all* of the information on unsubscribing
 that is available starting at this URL.

-- 

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: upload cygcheck-dep to noarch directory

[Jon Turney]

On 09/04/2018 13:44, Mikhail Usenko via cygwin-apps wrote:


Please, move cygcheck-dep to noarch/release hierarchy, so that the new version
can be uploaded appropriately.



Done.  Sorry for the inconvenience.

upload cygcheck-dep to noarch directory

[Mikhail Usenko via cygwin-apps]

Please, move cygcheck-dep to noarch/release hierarchy, so that the new version
can be uploaded appropriately.
-- 

Re: cygcheck-dep and _obsolete packages

[Mikhail Usenko via cygwin]

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://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck-dep and _obsolete packages

[Jon Turney]

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: broken dependencies:
/usr/bin/cygcheck-dep:   installed package 'cygwin/xorg-server-devel'
/usr/bin/cygcheck-dep:   depends on the following required packages that are
/usr/bin/cygcheck-dep:   not installed; these dependencies will be discarded
/usr/bin/cygcheck-dep: ( fontsproto inputproto kbproto presentproto
randrproto renderproto resourceproto scrnsaverproto xextproto
xf86bigfontproto xineramaproto xproto )



Hello, Marco
I will change the script (along with dropping cygwinports support).
At present cygcheck-dep prints out exactly what setup.ini claims about
what the package is requiring, and as per I have understood, now setup.exe
does not install requisites from the _obsolete category, using instead
the packages by which they are obsoleted.


Just to be clear, the category is irrelevant here, it's the fact that 
xorgproto obsoletes these packages that is significant.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck-dep and _obsolete packages

[Mikhail Usenko via cygwin]

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-dep:   installed package 'cygwin/xorg-server-devel'
> /usr/bin/cygcheck-dep:   depends on the following required packages that are
> /usr/bin/cygcheck-dep:   not installed; these dependencies will be discarded
> /usr/bin/cygcheck-dep: ( fontsproto inputproto kbproto presentproto 
> randrproto renderproto resourceproto scrnsaverproto xextproto 
> xf86bigfontproto xineramaproto xproto )
> 

Hello, Marco
I will change the script (along with dropping cygwinports support).
At present cygcheck-dep prints out exactly what setup.ini claims about
what the package is requiring, and as per I have understood, now setup.exe
does not install requisites from the _obsolete category, using instead
the packages by which they are obsoleted.

-- 


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygcheck-dep and _obsolete packages

[Marco Atzeri]

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-dep:   installed package 'cygwin/xorg-server-devel'
/usr/bin/cygcheck-dep:   depends on the following required packages that are
/usr/bin/cygcheck-dep:   not installed; these dependencies will be discarded
/usr/bin/cygcheck-dep: ( fontsproto inputproto kbproto presentproto 
randrproto renderproto resourceproto scrnsaverproto xextproto 
xf86bigfontproto xineramaproto xproto )


Thanks in advance
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck failing to find file

[Andrey Repin]

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 your link above but got "HTTP 404 Not found".
>> > Just in case this was your intention I tried the latest cygwin1.dll
>> > snapshot from
>> > https://cygwin.com/snapshots/
>> > being 20180216 but still got
>> >> $ cygcheck /d/src/sc.exe
>> >> cygcheck: could not find '/d/src/sc.exe'
>> 
>> > I just tried the 20180220 snapshot; but still get
>> >> $ cygcheck /d/src/sc.exe
>> >> cygcheck: could not find '/d/src/sc.exe'
>> 
>> For the third time, cygcheck is no Cygwin application, and unaware of Cygwin
>> paths.
>> Please give it native Windows paths.

> Incorrect.  Yes, cygcheck is a native Windows app, NO, you don't
> have to use Windows paths.

Sorry, my mistake. Happens, when threads are broken.


-- 
With best regards,
Andrey Repin
Wednesday, February 21, 2018 23:47:08

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck failing to find file

[Corinna Vinschen]

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 of the phrase
> >>> I pushed a fix and uploaded new developer snapshots to
> >>> https://cygwin.de/snapshots/
> >>> Please give them a try.
> was that something might have changed.
> Clearly an over-interpretation.

No, you just didn't use the new cygcheck, only a new Cygwin DLL.
See my reply https://cygwin.com/ml/cygwin/2018-02/msg00240.html


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: cygcheck failing to find file

[Fergus Daly]

> 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 developer snapshots to
>>> https://cygwin.de/snapshots/
>>> Please give them a try.
was that something might have changed.
Clearly an over-interpretation.
Fergus

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck failing to find file

[Corinna Vinschen]

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 I?  I'm constantly mixing up my
personal de domain with cygwin.com.  Sorry about that!

> Just in case this was your intention I tried the latest cygwin1.dll
> snapshot from
> https://cygwin.com/snapshots/
> being 20180216 but still got
> > $ cygcheck /d/src/sc.exe
> > cygcheck: could not find '/d/src/sc.exe'
> 
> I just tried the 20180220 snapshot; but still get
> > $ cygcheck /d/src/sc.exe
> > cygcheck: could not find '/d/src/sc.exe'

Apparently you only updated the Cygwin DLL, not the entire package
including the utilities packed with the DLL.  However, see the important
parts of my reply you snipped away:

  Cygcheck is a native Windows executable and thus does not use Cygwin's
   ^
  path handling (in contrast to md5sum, for instance).  Rather it uses a
  ^^
  home grown version and this in turn has a bug when checking the cygdrive
  ^^^
  prefix against the incoming path.  Everything goes, just not '/' alone.

So the patch I applied affected cygcheck, not the Cygwin DLL.


HTH,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: cygcheck failing to find file

[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 your link above but got "HTTP 404 Not found".
> > Just in case this was your intention I tried the latest cygwin1.dll
> > snapshot from
> > https://cygwin.com/snapshots/
> > being 20180216 but still got
> >> $ cygcheck /d/src/sc.exe
> >> cygcheck: could not find '/d/src/sc.exe'
> 
> > I just tried the 20180220 snapshot; but still get
> >> $ cygcheck /d/src/sc.exe
> >> cygcheck: could not find '/d/src/sc.exe'
> 
> For the third time, cygcheck is no Cygwin application, and unaware of Cygwin
> paths.
> Please give it native Windows paths.

Incorrect.  Yes, cygcheck is a native Windows app, NO, you don't
have to use Windows paths.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: cygcheck failing to find file

[Andrey Repin]

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 the latest cygwin1.dll
> snapshot from
> https://cygwin.com/snapshots/
> being 20180216 but still got
>> $ cygcheck /d/src/sc.exe
>> cygcheck: could not find '/d/src/sc.exe'

> I just tried the 20180220 snapshot; but still get
>> $ cygcheck /d/src/sc.exe
>> cygcheck: could not find '/d/src/sc.exe'

For the third time, cygcheck is no Cygwin application, and unaware of Cygwin
paths.
Please give it native Windows paths.


-- 
With best regards,
Andrey Repin
Wednesday, February 21, 2018 11:45:36

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck failing to find file

[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 the latest cygwin1.dll
snapshot from
https://cygwin.com/snapshots/
being 20180216 but still got
> $ cygcheck /d/src/sc.exe
> cygcheck: could not find '/d/src/sc.exe'

I just tried the 20180220 snapshot; but still get
> $ cygcheck /d/src/sc.exe
> cygcheck: could not find '/d/src/sc.exe'

Fergus

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck failing to find file

[Corinna Vinschen]

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
>  C:\Windows\system32\KERNEL32.dll
>  # but it all works
> 
> Now omit the need for /cygdrive/ by writing /etc/fstab as
> none / cygdrive binary 0 0
> and re-start Cygwin.
> 
> $ 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.)

Cygcheck is a native Windows executable and thus does not use Cygwin's
path handling (in contrast to md5sum, for instance).  Rather it uses a
home grown version and this in turn has a bug when checking the cygdrive
prefix against the incoming path.  Everything goes, just not '/' alone.

I pushed a fix and uploaded new developer snapshots to
https://cygwin.de/snapshots/

Please give them a try.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: cygcheck failing to find file

[Andrey Repin]

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. It works with native paths though.

$ uname -a; cygcheck /c/usr/sbin/php/php.exe; cygcheck "$( cygpath -wla 
/c/usr/sbin/php/php.exe )"
CYGWIN_NT-6.1 daemon2 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin
cygcheck: could not find '/c/usr/sbin/php/php.exe'

C:\usr\sbin\php\php.exe
  C:\Windows\system32\WS2_32.dll
C:\Windows\system32\msvcrt.dll
  C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\ntdll.dll


-- 
With best regards,
Andrey Repin
Thursday, February 15, 2018 22:17:50

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygcheck failing to find file

[Fergus Daly]

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
 C:\Windows\system32\KERNEL32.dll
 # but it all works

Now omit the need for /cygdrive/ by writing /etc/fstab as
none / cygdrive binary 0 0
and re-start Cygwin.

$ 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.)

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] cygcheck: Fix parsing of file names containing colons

[Corinna Vinschen]

On Oct 25 10:56, Ken Brown wrote:
> On 10/25/2017 10:19 AM, Corinna Vinschen wrote:
> > On Oct 25 09:38, Ken Brown wrote:
> > > On 10/25/2017 8:19 AM, Corinna Vinschen wrote:
> > > > On Oct 25 14:11, Corinna Vinschen wrote:
> > > > > Hi Ken,
> > > > > 
> > > > > On Oct 25 07:23, Ken Brown wrote:
> > > > > > Up to now the function winsup/utils/dump_setup.cc:base skips past
> > > > > > colons when parsing file names.  As a result, a line like
> > > > > > 
> > > > > > foo foo-1:2.3-4.tar.bz2 1
> > > > > > 
> > > > > > in /etc/setup/installed.db would cause 'cygcheck -cd foo' to report 
> > > > > > 4
> > > > > > as the installed version of foo insted of 1:2.3-4.  This is not an
> > > > > > issue now, but it will become an issue when version numbers are
> > > > > > allowed to contain epochs.
> > > > > > ---
> > > > > >winsup/utils/dump_setup.cc | 2 +-
> > > > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
> > > > > > index 320d69fab..3922b18f8 100644
> > > > > > --- a/winsup/utils/dump_setup.cc
> > > > > > +++ b/winsup/utils/dump_setup.cc
> > > > > > @@ -56,7 +56,7 @@ base (const char *s)
> > > > > >  const char *rv = s;
> > > > > >  while (*s)
> > > > > >{
> > > > > > -  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
> > > > > > +  if ((*s == '/' || *s == '\\') && s[1])
> > > > > 
> > > > > I think this is a simplified way to test for the colon in paths like
> > > > > C:/foo/bar.  Nothing else makes sense in this context.
> > > > > 
> > > > > I'm not sure how much we care, but maybe we shoulkd fix the test to
> > > > > ignore the colon only if it's the second character in the incoming
> > > > > string?
> > > > 
> > > > Not "ignore", but "use as a delimiter" only as 2nd char in the input.
> > > 
> > > I'm not sure the distinction matters in this case, since the function is
> > > just trying to get the base name.  Anyway, how's the attached?
> > 
> > Fine, thanks.
> > 
> > But now that you mention it... why does parse_filename() call base() at
> > all?  The filenames in installed.db are just basenames anyway.  Does
> > that cover an older DB format we don't support anymore, perhaps?
> 
> It looks like parse_filename is more-or-less copied from the function with
> the same name in the setup sources (in filemanip.cc).  In that case there
> might be a good reason to call base; I'll have to look more closely.
> 
> > I just wonder now if we should simply remove base() and the call to it.
> > 
> > Either way, you're right, the colon check is just useless, so your first
> > patch was entirely sufficient.
> > 
> > What do you think?  Stick to your patch or remove base()?
> 
> I vote for removing base.  The attached patch does this.

Pushed.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [PATCH] cygcheck: Fix parsing of file names containing colons

[Ken Brown]

On 10/25/2017 10:19 AM, Corinna Vinschen wrote:

On Oct 25 09:38, Ken Brown wrote:

On 10/25/2017 8:19 AM, Corinna Vinschen wrote:

On Oct 25 14:11, Corinna Vinschen wrote:

Hi Ken,

On Oct 25 07:23, Ken Brown wrote:

Up to now the function winsup/utils/dump_setup.cc:base skips past
colons when parsing file names.  As a result, a line like

foo foo-1:2.3-4.tar.bz2 1

in /etc/setup/installed.db would cause 'cygcheck -cd foo' to report 4
as the installed version of foo insted of 1:2.3-4.  This is not an
issue now, but it will become an issue when version numbers are
allowed to contain epochs.
---
   winsup/utils/dump_setup.cc | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
index 320d69fab..3922b18f8 100644
--- a/winsup/utils/dump_setup.cc
+++ b/winsup/utils/dump_setup.cc
@@ -56,7 +56,7 @@ base (const char *s)
 const char *rv = s;
 while (*s)
   {
-  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
+  if ((*s == '/' || *s == '\\') && s[1])


I think this is a simplified way to test for the colon in paths like
C:/foo/bar.  Nothing else makes sense in this context.

I'm not sure how much we care, but maybe we shoulkd fix the test to
ignore the colon only if it's the second character in the incoming
string?


Not "ignore", but "use as a delimiter" only as 2nd char in the input.


I'm not sure the distinction matters in this case, since the function is
just trying to get the base name.  Anyway, how's the attached?


Fine, thanks.

But now that you mention it... why does parse_filename() call base() at
all?  The filenames in installed.db are just basenames anyway.  Does
that cover an older DB format we don't support anymore, perhaps?


It looks like parse_filename is more-or-less copied from the function 
with the same name in the setup sources (in filemanip.cc).  In that case 
there might be a good reason to call base; I'll have to look more closely.



I just wonder now if we should simply remove base() and the call to it.

Either way, you're right, the colon check is just useless, so your first
patch was entirely sufficient.

What do you think?  Stick to your patch or remove base()?


I vote for removing base.  The attached patch does this.

Ken
From f679462937faf263de682c47f8d8e73b0c7e4136 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbr...@cornell.edu>
Date: Tue, 24 Oct 2017 18:21:53 -0400
Subject: [PATCH] winsup/utils/dump_setup.cc: Remove the function 'base'

This was called only on filenames in /etc/setup/installed.db, which
are all basenames anyway.  Moreover, base wasn't correctly handling
filenames containing colons.
---
 winsup/utils/dump_setup.cc | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
index 320d69fab..4415954f9 100644
--- a/winsup/utils/dump_setup.cc
+++ b/winsup/utils/dump_setup.cc
@@ -48,21 +48,6 @@ find_tar_ext (const char *path)
 return 0;
 }
 
-static char *
-base (const char *s)
-{
-  if (!s)
-return 0;
-  const char *rv = s;
-  while (*s)
-{
-  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
-   rv = s + 1;
-  s++;
-}
-  return (char *) rv;
-}
-
 /* Parse a filename into package, version, and extension components. */
 int
 parse_filename (const char *in_fn, fileparse& f)
@@ -79,7 +64,7 @@ parse_filename (const char *in_fn, fileparse& f)
   strcpy (f.tail, fn + n);
   fn[n] = '\0';
   f.pkg[0] = f.what[0] = '\0';
-  p = base (fn);
+  p = fn;
   for (ver = p; *ver; ver++)
 if (*ver != '-')
   continue;
-- 
2.14.2

Re: [PATCH] cygcheck: Fix parsing of file names containing colons

[Corinna Vinschen]

On Oct 25 09:38, Ken Brown wrote:
> On 10/25/2017 8:19 AM, Corinna Vinschen wrote:
> > On Oct 25 14:11, Corinna Vinschen wrote:
> > > Hi Ken,
> > > 
> > > On Oct 25 07:23, Ken Brown wrote:
> > > > Up to now the function winsup/utils/dump_setup.cc:base skips past
> > > > colons when parsing file names.  As a result, a line like
> > > > 
> > > >    foo foo-1:2.3-4.tar.bz2 1
> > > > 
> > > > in /etc/setup/installed.db would cause 'cygcheck -cd foo' to report 4
> > > > as the installed version of foo insted of 1:2.3-4.  This is not an
> > > > issue now, but it will become an issue when version numbers are
> > > > allowed to contain epochs.
> > > > ---
> > > >   winsup/utils/dump_setup.cc | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
> > > > index 320d69fab..3922b18f8 100644
> > > > --- a/winsup/utils/dump_setup.cc
> > > > +++ b/winsup/utils/dump_setup.cc
> > > > @@ -56,7 +56,7 @@ base (const char *s)
> > > > const char *rv = s;
> > > > while (*s)
> > > >   {
> > > > -  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
> > > > +  if ((*s == '/' || *s == '\\') && s[1])
> > > 
> > > I think this is a simplified way to test for the colon in paths like
> > > C:/foo/bar.  Nothing else makes sense in this context.
> > > 
> > > I'm not sure how much we care, but maybe we shoulkd fix the test to
> > > ignore the colon only if it's the second character in the incoming
> > > string?
> > 
> > Not "ignore", but "use as a delimiter" only as 2nd char in the input.
> 
> I'm not sure the distinction matters in this case, since the function is
> just trying to get the base name.  Anyway, how's the attached?

Fine, thanks.

But now that you mention it... why does parse_filename() call base() at
all?  The filenames in installed.db are just basenames anyway.  Does
that cover an older DB format we don't support anymore, perhaps?

I just wonder now if we should simply remove base() and the call to it.

Either way, you're right, the colon check is just useless, so your first
patch was entirely sufficient.

What do you think?  Stick to your patch or remove base()?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [PATCH] cygcheck: Fix parsing of file names containing colons

[Ken Brown]

On 10/25/2017 8:19 AM, Corinna Vinschen wrote:

On Oct 25 14:11, Corinna Vinschen wrote:

Hi Ken,

On Oct 25 07:23, Ken Brown wrote:

Up to now the function winsup/utils/dump_setup.cc:base skips past
colons when parsing file names.  As a result, a line like

   foo foo-1:2.3-4.tar.bz2 1

in /etc/setup/installed.db would cause 'cygcheck -cd foo' to report 4
as the installed version of foo insted of 1:2.3-4.  This is not an
issue now, but it will become an issue when version numbers are
allowed to contain epochs.
---
  winsup/utils/dump_setup.cc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
index 320d69fab..3922b18f8 100644
--- a/winsup/utils/dump_setup.cc
+++ b/winsup/utils/dump_setup.cc
@@ -56,7 +56,7 @@ base (const char *s)
const char *rv = s;
while (*s)
  {
-  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
+  if ((*s == '/' || *s == '\\') && s[1])


I think this is a simplified way to test for the colon in paths like
C:/foo/bar.  Nothing else makes sense in this context.

I'm not sure how much we care, but maybe we shoulkd fix the test to
ignore the colon only if it's the second character in the incoming
string?


Not "ignore", but "use as a delimiter" only as 2nd char in the input.


I'm not sure the distinction matters in this case, since the function is 
just trying to get the base name.  Anyway, how's the attached?


Ken
From 1354e67e12819519f9a5440f12ef893e4e0bf7a5 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbr...@cornell.edu>
Date: Tue, 24 Oct 2017 18:21:53 -0400
Subject: [PATCH] cygcheck: Fix parsing of file names containing colons

Up to now the function winsup/utils/dump_setup.cc:base skips past
colons when parsing file names.  As a result, a line like

  foo foo-1:2.3-4.tar.bz2 1

in /etc/setup/installed.db would cause 'cygcheck -cd foo' to report 4
as the installed version of foo insted of 1:2.3-4.  This is not an
issue now, but it will become an issue when version numbers are
allowed to contain epochs.
---
 winsup/utils/dump_setup.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
index 320d69fab..d05817239 100644
--- a/winsup/utils/dump_setup.cc
+++ b/winsup/utils/dump_setup.cc
@@ -53,10 +53,12 @@ base (const char *s)
 {
   if (!s)
 return 0;
+  if (isalpha (*s) && s[1] == ':')
+s += 2;
   const char *rv = s;
   while (*s)
 {
-  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
+  if ((*s == '/' || *s == '\\') && s[1])
rv = s + 1;
   s++;
 }
-- 
2.14.2

Re: [PATCH] cygcheck: Fix parsing of file names containing colons

[Corinna Vinschen]

On Oct 25 14:11, Corinna Vinschen wrote:
> Hi Ken,
> 
> On Oct 25 07:23, Ken Brown wrote:
> > Up to now the function winsup/utils/dump_setup.cc:base skips past
> > colons when parsing file names.  As a result, a line like
> > 
> >   foo foo-1:2.3-4.tar.bz2 1
> > 
> > in /etc/setup/installed.db would cause 'cygcheck -cd foo' to report 4
> > as the installed version of foo insted of 1:2.3-4.  This is not an
> > issue now, but it will become an issue when version numbers are
> > allowed to contain epochs.
> > ---
> >  winsup/utils/dump_setup.cc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
> > index 320d69fab..3922b18f8 100644
> > --- a/winsup/utils/dump_setup.cc
> > +++ b/winsup/utils/dump_setup.cc
> > @@ -56,7 +56,7 @@ base (const char *s)
> >const char *rv = s;
> >while (*s)
> >  {
> > -  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
> > +  if ((*s == '/' || *s == '\\') && s[1])
> 
> I think this is a simplified way to test for the colon in paths like
> C:/foo/bar.  Nothing else makes sense in this context.
> 
> I'm not sure how much we care, but maybe we shoulkd fix the test to
> ignore the colon only if it's the second character in the incoming
> string?

Not "ignore", but "use as a delimiter" only as 2nd char in the input.

Sorry,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [PATCH] cygcheck: Fix parsing of file names containing colons

[Corinna Vinschen]

Hi Ken,

On Oct 25 07:23, Ken Brown wrote:
> Up to now the function winsup/utils/dump_setup.cc:base skips past
> colons when parsing file names.  As a result, a line like
> 
>   foo foo-1:2.3-4.tar.bz2 1
> 
> in /etc/setup/installed.db would cause 'cygcheck -cd foo' to report 4
> as the installed version of foo insted of 1:2.3-4.  This is not an
> issue now, but it will become an issue when version numbers are
> allowed to contain epochs.
> ---
>  winsup/utils/dump_setup.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
> index 320d69fab..3922b18f8 100644
> --- a/winsup/utils/dump_setup.cc
> +++ b/winsup/utils/dump_setup.cc
> @@ -56,7 +56,7 @@ base (const char *s)
>const char *rv = s;
>while (*s)
>  {
> -  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
> +  if ((*s == '/' || *s == '\\') && s[1])

I think this is a simplified way to test for the colon in paths like
C:/foo/bar.  Nothing else makes sense in this context.

I'm not sure how much we care, but maybe we shoulkd fix the test to
ignore the colon only if it's the second character in the incoming
string?


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[PATCH] cygcheck: Fix parsing of file names containing colons

[Ken Brown]

Up to now the function winsup/utils/dump_setup.cc:base skips past
colons when parsing file names.  As a result, a line like

  foo foo-1:2.3-4.tar.bz2 1

in /etc/setup/installed.db would cause 'cygcheck -cd foo' to report 4
as the installed version of foo insted of 1:2.3-4.  This is not an
issue now, but it will become an issue when version numbers are
allowed to contain epochs.
---
 winsup/utils/dump_setup.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/utils/dump_setup.cc b/winsup/utils/dump_setup.cc
index 320d69fab..3922b18f8 100644
--- a/winsup/utils/dump_setup.cc
+++ b/winsup/utils/dump_setup.cc
@@ -56,7 +56,7 @@ base (const char *s)
   const char *rv = s;
   while (*s)
 {
-  if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
+  if ((*s == '/' || *s == '\\') && s[1])
rv = s + 1;
   s++;
 }
-- 
2.14.2

Re: cygcheck -f reorders output

[Brian Inglis]

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 challenge to match the output with the parameters.

Depends on what you want to do with it?
Use a loop thru the names and use which then cygcheck on each.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck -f reorders output

[Marco Atzeri]

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 output with the parameters.



it is a side effect of the order of search in the
/etc/setup/*.gz file list.
The first match is reported first and so on.

To maintain the order

$ for i in  `which bash find grep xargs cygwin1.dll`;
  do cygcheck -f $i;done

bash-4.4.12-3
findutils-4.6.0-1
grep-3.0-2
findutils-4.6.0-1
cygwin-2.9.0-3

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygcheck -f reorders output

[Nellis, Kenneth]

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 output with the parameters.

--Ken Nellis

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: httping requires libfftw3_3 (cygcheck report)

[Jon Turney]

On 14/08/2017 10:13, bugz bunnyz via cygwin wrote:

httping is not working without libfftw3_3 (cygcheck /bin/httping.exe fail)
libfftw3_3 needs to be in requires list (I have to install it manually)


Thanks for reporting this.

I have fixed the dependency for httping on sourceware.

Jari,

You might want to consider updating your local copy you have.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

httping requires libfftw3_3 (cygcheck report)

[bugz bunnyz via cygwin]

Hi

httping is not working without libfftw3_3 (cygcheck /bin/httping.exe fail)
libfftw3_3 needs to be in requires list (I have to install it manually)

@ httping
sdesc: "Ping-like program for http-requests"
ldesc: "Show how long it takes to connect to a hostname or remote
url; send a request and retrieve the reply (only the headers)."
category: Web
requires: libgcc1 libopenssl100
version: 2.4+20151029+gitb1521a6-1

@ libfftw3_3
sdesc: "Fast Fourier transforms C library - runtime"
ldesc: "Fast Fourier transforms C library"
category: Libs Math
requires: cygwin
version: 3.3.6-pl1-1

cygwin setup 2.881 (64 bit)

best regards,
Mit
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug in cygcheck -- claims missing files, but files are not missing.

[Andrey Repin]

Greetings, L A Walsh!

> L A Walsh wrote:
>> Andrey Repin wrote:
>>> Greetings, L A Walsh!
>> Hi Andrey Repin! ;-)
>>>> Any idea how to figure out what cygcheck is doing?
>>>
>>> How did you invoke cygcheck?
>>> I've seen similar behavior when invoking it as /usr/bin/cygcheck 
>>> outside the Cygwin environment.
>> 
>>
>> I invoked it from bash at the same place I typed 'll' (ls -l).
>>
>> It's very confusing -- have run it more than once, since
>> I do have some missing files, but not the number of
>> files cygcheck lists. 
>> Thanks...
> ---
> I think I may be on the path to sorting this out... it seemed to be
> looking in another directory created by the install process (vs.
> the previously existing one, which it ignored), having to do
> with the old path being valid by using Windows-soft-mounts (junctions),
> and cygwin overwriting/deleting them because cygwin conflates
> junctions and symlinks and treats them the same, losing any
> windows-configuration difference. 

> Usually it's not so much of a problem, as I haven't upgraded my
> cygwin SW for some time.  But I forgot how much of a pain it is
> because it messes things up every time I run setup (sigh).

> It's hard to get the SW installed in the right place when it
> keeps overwriting soft-mounts.

May be a zp_ (or 0p_) postinstall script could help?


-- 
With best regards,
Andrey Repin
Monday, April 17, 2017 18:49:10

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug in cygcheck -- claims missing files, but files are not missing.

[L A Walsh]

L A Walsh wrote:

Andrey Repin wrote:

Greetings, L A Walsh!

Hi Andrey Repin! ;-)

Any idea how to figure out what cygcheck is doing?


How did you invoke cygcheck?
I've seen similar behavior when invoking it as /usr/bin/cygcheck 
outside the Cygwin environment.



I invoked it from bash at the same place I typed 'll' (ls -l).

It's very confusing -- have run it more than once, since
I do have some missing files, but not the number of
files cygcheck lists. 
Thanks...

---
   I think I may be on the path to sorting this out... it seemed to be
looking in another directory created by the install process (vs.
the previously existing one, which it ignored), having to do
with the old path being valid by using Windows-soft-mounts (junctions),
and cygwin overwriting/deleting them because cygwin conflates
junctions and symlinks and treats them the same, losing any
windows-configuration difference. 


Usually it's not so much of a problem, as I haven't upgraded my
cygwin SW for some time.  But I forgot how much of a pain it is
because it messes things up every time I run setup (sigh).

It's hard to get the SW installed in the right place when it
keeps overwriting soft-mounts.





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug in cygcheck -- claims missing files, but files are not missing.

[L A Walsh]

Andrey Repin wrote:

Greetings, L A Walsh!

Hi Andrey Repin! ;-)



Any idea how to figure out what cygcheck is doing?


How did you invoke cygcheck?
I've seen similar behavior when invoking it as /usr/bin/cygcheck outside the
Cygwin environment.



I invoked it from bash at the same place I typed 'll' (ls -l).

It's very confusing -- have run it more than once, since
I do have some missing files, but not the number of
files cygcheck lists.  


Thanks...
-linda


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: bug in cygcheck -- claims missing files, but files are not missing.

[Andrey Repin]

Greetings, L A Walsh!

> I am trying to update my cygwin installation --

> I seem to be missing some files, but am not sure, as cygcheck
> seems to be broken.

> I generated a dump using cygcheck -vs, and it claims
> may files are missing:

> Missing directory: /usr/share/doc/ from package afio
> Missing directory: /usr/share/doc/afio-2.5/ from package afio
> Missing file: /usr/share/doc/afio-2.5/ANNOUNCE-2.5 from package afio
> Missing file: /usr/share/doc/afio-2.5/HISTORY from package afio
> Missing file: /usr/share/doc/afio-2.5/README from package afio
> Missing file: /usr/share/doc/afio-2.5/SCRIPTS from package afio

> But when I look for them, they are not:

> /usr>  ll /usr/share/doc/afio-2.5
> total 48
> -rwxrwxr-x+ 1  1634 Feb 19  2008 ANNOUNCE-2.5*
> -rwxrwxr-x+ 1 33879 Feb 19  2008 HISTORY*
> -rwxrwxr-x+ 1  3116 Feb 19  2008 README*
> -rwxrwxr-x+ 1  2179 Feb 19  2008 SCRIPTS*
> drwxrwxr-x+ 1 0 Dec 13  2009 examples/

> Any idea how to figure out what cygcheck is doing?

How did you invoke cygcheck?
I've seen similar behavior when invoking it as /usr/bin/cygcheck outside the
Cygwin environment.


-- 
With best regards,
Andrey Repin
Saturday, April 15, 2017 15:14:15

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

bug in cygcheck -- claims missing files, but files are not missing.

[L A Walsh]

I am trying to update my cygwin installation --

I seem to be missing some files, but am not sure, as cygcheck
seems to be broken.

I generated a dump using cygcheck -vs, and it claims
may files are missing:

Missing directory: /usr/share/doc/ from package afio
Missing directory: /usr/share/doc/afio-2.5/ from package afio
Missing file: /usr/share/doc/afio-2.5/ANNOUNCE-2.5 from package afio
Missing file: /usr/share/doc/afio-2.5/HISTORY from package afio
Missing file: /usr/share/doc/afio-2.5/README from package afio
Missing file: /usr/share/doc/afio-2.5/SCRIPTS from package afio

But when I look for them, they are not:

/usr>  ll /usr/share/doc/afio-2.5
total 48
-rwxrwxr-x+ 1  1634 Feb 19  2008 ANNOUNCE-2.5*
-rwxrwxr-x+ 1 33879 Feb 19  2008 HISTORY*
-rwxrwxr-x+ 1  3116 Feb 19  2008 README*
-rwxrwxr-x+ 1  2179 Feb 19  2008 SCRIPTS*
drwxrwxr-x+ 1 0 Dec 13  2009 examples/

Any idea how to figure out what cygcheck is doing?

thanks!








--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: cygcheck outputs CRLF

[Cooper, Karl T (US)]

>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-like. Given an opportunity, >I would vote for it to use Unix line endings.

The question was asked about a month ago, and answered here:
https://cygwin.com/ml/cygwin/2017-01/msg00223.html

Karl
>--Ken Nellis



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygcheck outputs CRLF

[Nellis, Kenneth (Conduent)]

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-like. Given an opportunity, I would vote 
for it to use Unix line endings.

--Ken Nellis

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[newlib-cygwin] Fix handling of '+' by 'cygcheck -p'

[Jon TURNEY]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a15297381df27a5e53eab42fe5c475e2aa55f559

commit a15297381df27a5e53eab42fe5c475e2aa55f559
Author: Jon Turney <jon.tur...@dronecode.org.uk>
Date:   Mon Jan 30 15:04:28 2017 +

Fix handling of '+' by 'cygcheck -p'

The form data sent to the server should be application/x-www-form-urlencoded

This replaces spaces with '+' before being RFC 1738 encoded, so a literal
'+' must be %-encoded also.

See https://cygwin.com/ml/cygwin/2014-01/msg00287.html et seq.

Signed-off-by: Jon Turney <jon.tur...@dronecode.org.uk>

Diff:
---
 winsup/utils/cygcheck.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/winsup/utils/cygcheck.cc b/winsup/utils/cygcheck.cc
index d1e27b7..e745b20 100644
--- a/winsup/utils/cygcheck.cc
+++ b/winsup/utils/cygcheck.cc
@@ -2009,8 +2009,8 @@ check_keys ()
   return 0;
 }
 
-/* RFC1738 says that these do not need to be escaped.  */
-static const char safe_chars[] = "$-_.+!*'(),";
+/* These do not need to be escaped in application/x-www-form-urlencoded */
+static const char safe_chars[] = "$-_.!*'(),";
 
 /* the URL to query.  */
 static const char base_url[] =

Re: [PATCH] Fix cygcheck -p's handling of '+'

[Corinna Vinschen]

On Jan 30 15:37, Jon Turney wrote:
> The form data sent to the server should be application/x-www-form-urlencoded
> 
> This replaces spaces with '+' before being RFC 11738 encoded, so a literal
> '+' must be %-encoded also.
> 
> See https://cygwin.com/ml/cygwin/2014-01/msg00287.html et seq.
> 
> Signed-off-by: Jon Turney 
> ---
>  winsup/utils/cygcheck.cc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/winsup/utils/cygcheck.cc b/winsup/utils/cygcheck.cc
> index d1e27b7..e745b20 100644
> --- a/winsup/utils/cygcheck.cc
> +++ b/winsup/utils/cygcheck.cc
> @@ -2009,8 +2009,8 @@ check_keys ()
>return 0;
>  }
>  
> -/* RFC1738 says that these do not need to be escaped.  */
> -static const char safe_chars[] = "$-_.+!*'(),";
> +/* These do not need to be escaped in application/x-www-form-urlencoded */
> +static const char safe_chars[] = "$-_.!*'(),";
>  
>  /* the URL to query.  */
>  static const char base_url[] =
> -- 
> 2.8.3

Thanks, please apply.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: cygcheck and literal plus sign

[Steven Penny]

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/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cygcheck and literal plus sign

[Jon Turney]

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 again. package-grep does work:


Thanks for pointing this out.


$ q=https://cygwin.com/cgi-bin2/package-grep.cgi
$ curl -s "$q"'?text=1=x86_64=mingw32-g%2B%2B' | awk 'NR>1{$0=$1}1'
Found 4 matches for mingw32-g++
mingw64-i686-gcc-g++-5.4.0-2
mingw64-i686-gcc-g++-5.4.0-3
mingw64-x86_64-gcc-g++-5.4.0-2
mingw64-x86_64-gcc-g++-5.4.0-3

but it seems no incantation will make cygcheck work:

[...]


    $ cygcheck -p mingw32-g++
Found 0 matches for mingw32-g


It looks like the underlying bug here is that 'cygcheck -p' doesn't 
encode '+', but the package-grep-cgi script is expecting the query part 
of the URL to be application/x-www-form-urlencoded (as is the case with 
the web form interface to this search), where '+' is the encoding for a 
' '...


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



$ cygcheck -p mingw32-g++
Found 4 matches for mingw32-g++
mingw64-i686-gcc-g++-5.4.0-2 - mingw64-i686-gcc-g++: GCC for Win32 
(i686-w64-mingw32) toolchain (C++) (installed binaries and support files)
mingw64-i686-gcc-g++-5.4.0-3 - mingw64-i686-gcc-g++: GCC for Win32 
(i686-w64-mingw32) toolchain (C++) (installed binaries and support files)
mingw64-x86_64-gcc-g++-5.4.0-2 - mingw64-x86_64-gcc-g++: GCC for Win64 
toolchain (C++) (installed binaries and support files)
mingw64-x86_64-gcc-g++-5.4.0-3 - mingw64-x86_64-gcc-g++: GCC for Win64 
toolchain (C++) (installed binaries and support files)



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple