Bug#181872: Patch
On Thu, Mar 13, 2003 at 06:46:35PM +0100, Frank Lichtenheld wrote:
> > > --- pages.pl 30 Jan 2003 14:43:59 -0000 1.9
> > > +++ pages.pl 13 Mar 2003 14:30:56 -0000
> > > - $long_desc =~ s,<((URL:)?http://[\S~-]+?/?)>,\<\;$1\>\;,go;
> > > + $long_desc =~ s,<((URL:)?\s*http://[\S~-]+?/?)>,\<\;$1\>\;,go;
> > > + $long_desc =~ s/</\<\;/go;
> > > + $long_desc =~ s/>/\>\;/go;
> >
> > The right fix would be simply
> > $long_desc =~ s,<(?:URL:\s*)?(http://[^>]+)\s*>,\<\;$1\>\;,go;
> >
> > Right?
>
> Yours would do also. The main difference in result is that you delete
> the 'URL:' while mine preserves it. Only a cosmetic difference.
Actually I did that off the top of my head, focusing on the [^>] part.
I thought that the "URL:" part was included in the anchor, but I guess
that's handled by some other part of the code.
> > > + $long_desc =~ s/\&/\&\;/go;
> >
> > That sounds like a fix for another bug, and it doesn't look like it would
> > actually handle the read &s in descriptions...
>
> You're right, that this line (also the two other above) are not
> related to the bug. But i don't understand your problem with it. It is
> actually a fault to have bare &'s in the html-Code (look at the
> example site from the bug one paragraph above).
The problem is that if someone puts a proper & in a URL, your regexp
would happily convert it to &amp; :)
--
2. That which causes joy or happiness.
Reply to: