From: Jakub Narebski <jnareb@gmail.com>
To: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: git@vger.kernel.org
Subject: [PATCH (BUGFIX)] gitweb: Fix fixed string (non-regexp) project search
Date: Fri, 2 Mar 2012 23:34:24 +0100 [thread overview]
Message-ID: <201203022334.25544.jnareb@gmail.com> (raw)
In-Reply-To: <4F512327.3050504@ramsay1.demon.co.uk>
Use $search_regexp, where regex metacharacters are quoted, for
searching projects list, rather than $searchtext, which contains
original search term.
Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I think this bug was here from the very beginning of adding project
search, i.e. from v1.6.0.2-446-g0d1d154 (gitweb: Support for simple
project search form, 2008-10-03) which was present since 1.6.1
On Fri, 2 Mar 2012, Ramsay Jones wrote:
> Jakub Narebski wrote:
> > When using regexp search ('sr' parameter / $search_use_regexp variable
> > is true), check first that regexp is valid.
> >
> > Without this patch we would get an error from Perl during search (if
> > searching is performed by gitweb), or highlighting matches substring
> > (if applicable), if user provided invalid regexp... which means broken
> > HTML, with error page (including HTTP headers) generated after gitweb
> > already produced some output.
> >
> > Add test that illustrates such error: for example for regexp "*\.git"
> > we would get the following error:
> >
> > Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE \.git/
> > at /var/www/cgi-bin/gitweb.cgi line 3084.
> >
> > Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> > Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> > ---
> > See "Re: gitweb: (potential) problems with new installation"
> > http://thread.gmane.org/gmane.comp.version-control.git/191746
>
> This patch solves the problem for me when using a regex search
> (re checkbox checked), but *not* for a non-regex search.
>
> If you have a leading '*' or '+', in the non-regex case, then you
> still get the above complaint (and xml error page etc.), although
> the line number has changed slightly from that given above.
Ramsay, please provide those line number in the future, together with
line and if possible some context.
The line is different because it is different bug: this is about not
using quotemeta'ed string for search for fixed-string search.
gitweb/gitweb.perl | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 22ad279..7398be1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3072,16 +3072,16 @@ sub filter_forks_from_projects_list {
# for 'descr_long' and 'ctags' to be filled
sub search_projects_list {
my ($projlist, %opts) = @_;
- my $tagfilter = $opts{'tagfilter'};
- my $searchtext = $opts{'searchtext'};
+ my $tagfilter = $opts{'tagfilter'};
+ my $search_re = $opts{'search_regexp'};
return @$projlist
- unless ($tagfilter || $searchtext);
+ unless ($tagfilter || $search_re);
# searching projects require filling to be run before it;
fill_project_list_info($projlist,
- $tagfilter ? 'ctags' : (),
- $searchtext ? ('path', 'descr') : ());
+ $tagfilter ? 'ctags' : (),
+ $search_re ? ('path', 'descr') : ());
my @projects;
PROJECT:
foreach my $pr (@$projlist) {
@@ -3092,10 +3092,10 @@ sub search_projects_list {
grep { lc($_) eq lc($tagfilter) } keys %{$pr->{'ctags'}};
}
- if ($searchtext) {
+ if ($search_re) {
next unless
- $pr->{'path'} =~ /$searchtext/ ||
- $pr->{'descr_long'} =~ /$searchtext/;
+ $pr->{'path'} =~ /$search_re/ ||
+ $pr->{'descr_long'} =~ /$search_re/;
}
push @projects, $pr;
@@ -5498,9 +5498,9 @@ sub git_project_list_body {
if ($check_forks);
# search_projects_list pre-fills required info
@projects = search_projects_list(\@projects,
- 'searchtext' => $searchtext,
- 'tagfilter' => $tagfilter)
- if ($tagfilter || $searchtext);
+ 'search_regexp' => $search_regexp,
+ 'tagfilter' => $tagfilter)
+ if ($tagfilter || $search_regexp);
# fill the rest
@projects = fill_project_list_info(\@projects);
--
1.7.9
next prev parent reply other threads:[~2012-03-02 22:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 18:41 [PATCH (BUGFIX)] gitweb: Handle invalid regexp in regexp search Jakub Narebski
2012-02-28 19:45 ` Junio C Hamano
2012-02-29 15:56 ` Jakub Narebski
2012-03-02 19:44 ` Ramsay Jones
2012-03-02 22:34 ` Jakub Narebski [this message]
2012-03-03 0:08 ` [PATCH (BUGFIX)] gitweb: Fix fixed string (non-regexp) project search Junio C Hamano
2012-03-03 10:55 ` Jakub Narebski
2012-03-04 9:35 ` [PATCH (for maint)] " Jakub Narebski
2012-03-05 5:16 ` Junio C Hamano
2012-03-05 8:59 ` Jakub Narebski
2012-03-05 17:01 ` Junio C Hamano
2012-03-05 23:27 ` Junio C Hamano
2012-03-06 11:59 ` Jakub Narebski
2012-03-04 18:00 ` [PATCH (BUGFIX)] " Jakub Narebski
2012-03-04 23:08 ` Junio C Hamano
2012-03-05 9:03 ` Jakub Narebski
2012-03-05 19:06 ` Ramsay Jones
2012-03-06 12:40 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201203022334.25544.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=ramsay@ramsay1.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).