Martin Simmons wrote:
On Tue, 29 Nov 2005 16:03:27 +0100, =?ISO-8859-1?Q?Attila_F=FCl=F6p?= <[EMAIL 
PROTECTED]> said:


  Attila> Martin Simmons wrote:
  >>>>>>> On Tue, 29 Nov 2005 15:09:48 +0100, =?ISO-8859-1?Q?Attila_F=FCl=F6p?= 
<[EMAIL PROTECTED]> said:
>> >> Attila> Kern Sibbald wrote: >> >> >> On Monday 28 November 2005 19:38, Martin Simmons wrote: >> >> >> >>>>>>>> On Mon, 28 Nov 2005 17:06:00 +0100, Kern Sibbald <[EMAIL PROTECTED]>
  >> >>>>>>>> said:
>> >>> >> >>> Kern> On Monday 28 November 2005 15:55, Martin Simmons wrote:
  >> >>> >> >>>>> On Fri, 25 Nov 2005 09:21:29 +0000, Greg Cope
  >> >>> >> >>>>> <[EMAIL PROTECTED]> said:
>> >>> Greg> I am trying to glob a load of oracle backup files. As per Stephan
  Greg> Ebelt's post these will be under /uNN dirs that are often on
>> >>> >> >>> >> different Greg> file systems. >> >>> Greg> What I am trying to do is; >> >>> Greg> regex = "^\/u[0-9]{2}\/(oraback|oraarch)" >> >>> Greg> But the following fail to match anything bar '/' >> >>> Greg> regex = "^\/u[0-9]{2}\/(oraback|oraarch)"
  Greg> regex = "^\/u[0-9]{2}\/oraexp"
  Greg> regex = "^\/u[0-9]{2}\/oraback"
  Greg> regex = "^\/u[0-9]{2}.oraback"
>> >>> Greg> As expected regex = "^\/u[0-9]{2}" matches the lot. >> >>> Greg> Can anyone shed any light on this or the regex code? >> >>> >> >>> >> The problem is that Bacula walks down the tree of directories looking
  >> >>> >> for matching include/exclude patterns.  When it finds an excluded
  >> >>> >> directory, it doesn't look any deeper in that directory.  Now /u02
  >> >>> >> doesn't match any of the above, so it stops the walk before
  >> >>> >> /u02/oraback is found.
  >> >>> >>
  >> >>> >> BTW, I don't think you need \ before / in a regex.
>> >>> Kern> Recently, I added something similar to this example to the FileSet
  >> >>> chapter of Kern> the manual.  It would be interesting to know what you
  >> >>> think about the example Kern> Martin since I haven't actually "run" 
it.  Of
  >> >>> course, the example doesn't Kern> deal with more complex issues such as
  >> >>> traversing subdirectories where parents Kern> may be excluded ...
>> >>> >> >>> I found the new examples, but what the ^.?*$ is "^.?*$" supposed to mean? >> >> Attila> If we are talking about extended regexp "^.?*$" indeed is a sytax error. There
  Attila> must be something in front of the *. You could say "^.?.*$" but this 
is the
  Attila> same as "^.*$".
>> >> >> >> >> Match the whole line no matter what it contains. .* doesn't seem to work on Linux ... >> >> Attila> Mhh if it doesn't work you're using basic regular expressions. (And it means
  Attila> a line containing any number of dots) And then "^.?*$" works and 
means the
  Attila> same as "^*$".
>> >> The regexp syntax (basic/extended) is chosen then regcomp() is called and
  >> AFAICS bacula uses extended.  The .* regexp filters the files correctly 
for me
  >> on FreeBSD.
  >> There is a slight problem though: all of the directories are included, even
  >> those containing no included files.  This is a design issue, not a bug in
  >> regexp matching.
>>
  Attila> Sorry, for the misunderstanding. I was referring to the fact that 
"^.?*$" does not
  Attila> work on FreeBSD and works on Linux, whereas "^.*$" does not work on 
Linux. This is a
  Attila> clear indication for me that for some reasons bacula on FreeBSD uses 
extended regexp
  Attila> but on Linux basic ones are used. I wasn't referring to your include 
problem though.

OK, I see.
I just checked on Linux (glibc-2.3.3-74) and "^.?*$" doesn't raise a parse
error in extended mode. Not sure what they think it means though!

Dunno either. According to re_format(7): "A piece is an atom possibly followed 
by a
single `*', `+', `?', or bound." So .?* should violate this statement. Looks 
like
a bug, maybe the '?' is silently discarded, that would explain why it works.
Can you reproduce "^.*$" not matching any line, as Kern mentioned?

Nonesense
like "(*)" does raise an error, so we're definitely not in basic mode.

Right.

__Martin




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to