On Friday 27 October 2017 at 17:06:01, Yuri wrote:
> 27.10.2017 20:55, Alex Rousskov пишет:
> >
> > When a regular expression is using extended features, the basic regular
> > expression compiler often (or even always?!) does not fail because it
> > views the extended features as ordinary plain characters. Thus, Squid
> > cannot tell that something went wrong.
> >> $ echo "foobar" | grep --basic-regexp 'foo|bar'
> >> $ echo "foobar" | grep --extended-regexp 'foo|bar'
> >> foobar
> >
> > As you can see, the basic compiler is silent about the "|" character
> > that it does not support. Here is a similar example where a malformed
> >
> > extended regular expression is silently accepted by the basic compiler:
> >> $ echo "foobar" | grep --basic-regexp 'foo(bar'
> >> $ echo "foobar" | grep --extended-regexp 'foo(bar'
> >> grep: Unmatched ( or \(
> I would like either a clear documentation
That sounds entirely reasonable - a statement something like "Squid is
guaranteed to use basic POSIX grammar, but extended grammar may be available
on different systems; the sysadmin should check"?
> or some tool for checking whether the regular expression is correct from the
> point of view of the current library used by Squid or not.
What does "correct" mean?
As Alex's examples above demonstrate, both are "correct" regexes from the
basic POSIX point of view; they just don't do what the admin might have wanted
or expected.
How could Squid know whether you expect ( in a regex to be a literal character
or a meta-character?
> The existing opportunities seem completely unsatisfactory.
Nothing documents that Squid uses other than basic POSIX grammar, so why would
you assume that it does?
Antony.
--
It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.
- Daniel C Dennett
Please reply to the list;
please *don't* CC me.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
