[PATCH (BUGFIX)] gitweb: Fix fixed string (non-regexp) project search
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Mar 2, 2012, 22:34 UTC
- Message-ID
- <201203022334.25544.jnareb@gmail.com>
- 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:
Show 27 quoted lines
> > 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