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&arch=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&arch=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 '<li><a href="package-cat.cgi?file='`urlencode
$partfile`'&grep='`urlencode $param_grep`'">'$file'</a> -
'$desc'</li>'
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
