My 2c. It's not uncommon for a scripting language (and syslog-ng.conf is that in a sense) to require you to quote regular expressions carefully, especially if you're trying to have a character like [ taken literally. I've been working with regular expressions a lot recently in Tcl, bash and Perl scripts and getting the quoting of special characters right is always difficult. That's why I spotted immediately that the problem reported here was probably just that the \ itself needed quoting so it would go through to the expression parser verbatim - I had a similar fight with Tcl a few weeks ago. So I don't believe that there is anything fundamentally wrong or more complex with quoting regular expressions in the syslog-ng environment. It can be a pain, that's the size of it. Joe. PS: btw tclsh is great for debugging regular expressions interactively. If anyone would like examples of how to use it for that please let me know. -----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: 04 October 2008 12:49 To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] escaping \[ not respected On Thu, 2008-10-02 at 08:51 -0700, Evan Rempel wrote:
Balazs Scheidler wrote:
On Thu, 2008-10-02 at 09:12 +1300, chris packham wrote:
One option would be to use the kind quotes ' vs " to determine whether to escape or not. I believe bash (and maybe perl) does this kind of thing when handling strings.
Yeah, the problem is with compatibility, ' and " style quoting has been working this way for about a decade, changing that would break a lot of configurations.
I should have made this decision back then, but changing this now is not really possible I think.
Perhaps adding a new config keyword
match_pcre(/no syslog-ng escape codes, all escapes are handled by the pcre evaluation/)
The down side to this is that you really need to have program_pcre and any other additions along those lines. Things get a little messy. Hopefully in a later version the normal match, program directives could be made to work this way, and the match_pcre etc would become backwards compatible aliases to the non_pcre commands.
I don't really like that solution, but I thought I would "throw it out there".
This is quiet ugly. The problem is that I could also come up only with ugly solutions.
Another option is to an something like is already present for the templates where there is a template_escape(no) option. If you add a regex_escape(yes/no) directive and default to yes, then all of the current expressions would work.
If you do not need to have quotes in your expression, then you can use regex_escape(no) and do away with the escapes for the escapes.
This is not currently possible, the lexes resolves the escapes before even going to the parser.. -- Bazsi ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html