On Monday 03 September 2007 23:49, Martin Simmons wrote:
> >>>>> On Mon, 3 Sep 2007 21:29:24 +0200, Kern Sibbald said:
> >
> > On Monday 03 September 2007 20:28, Eric Bollengier wrote:
> > > On Monday 03 September 2007 19:12:12 Kern Sibbald wrote:
> > > > On Monday 03 September 2007 18:44, Eric Bollengier wrote:
> > > > > Hi,
> > > > >
> > > > > It's why we provide the bwild tool... If you are using something
> > > > > special, you can validate your expression with this tool.
> > > >
> > > > I don't imagine that you were directing that comment at me -- since I
> > > > was the person who wrote bwild :-)
> > >
> > > Yes i know :)
> > >
> > > I have looked some implementations of fnmatch and all of them are
> > > trying to respect the POSIX interface, but it's sure that some of them
> > > are wrong :-)
> > >
> > > glibc tests are better than before :
> > > [18] [/b matches [/b -> FAIL
> >
> > To the best of my knowledge the following are not wildcard matches. If
> > they are can you point me to the definition of [:alpha:]?
> >
> > > [36] *[[:alpha:]]/*[[:alnum:]] does not match a/b -> FAIL
> > > [37] *[![:digit:]]*/[![:d-d] does not match a/b -> FAIL
> > > [38] *[![:digit:]]*/[[:d-d] does not match a/[ -> FAIL
> >
> > I think they have a broken test set -- someone confused wildcards and
> > regular expressions, or defined the test results backwards.
> >
> > >From every definition I can find, wildcards included in fnmatch, contain
> > > only
> >
> > *
> > ?
> > [set]
> > [!set]
> >
> > anything else is an extension that is not in basic shell wildcards or
> > something from regular expressions. You need to be careful because a lot
> > of documents refer to regular expressions as wildcards, but as you know,
> > they are not at all the same thing.
>
> The [:class:] might come from POSIX. It is certainly allowed by this spec:
>
> http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag
>_02_06_06
> http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag
>_02_13
Thanks for the references. This is exactly what I was looking for.
>
> > I have seen some documents that claim that {stringa,stringb} matches
> > stringa or stringb, but that seems to be rare, and in any case, it is not
> > implemented in the basic BSD fnmatch.
>
> I think there is confusion between "matching" and "expansion" -- we are
> doing matching here.
>
> The {stringa,stringb} syntax in the shell is string expansion and the
> fnmatch-style wildcards are for pathname expansion. The difference is that
> the fnmatch-style wildcards generate names based on the filesystem, whereas
> {} syntax generates names based only on the string.
The following is not in response to Martin's explanation, but rather a general
observation of mine for all Bacula users:
I think it may be interesting to have the {}, but given that we have many more
things to implement than we have programmers and that we have regexes, it is
probably better to stick with what we currently have less the EnhancedWild
features that I have proposed dropping ...
Regards,
Kern
>
> E.g.
>
> $ touch foo1 foo2
> $ echo foo[123]
> foo1 foo2
> $ echo foo{1,2,3}
> foo1 foo2 foo3
> $ echo foo[3]
> foo[3]
> $ echo foo{3}
> foo3
>
> __Martin
>
> > Kern
> >
> > > [36] *[[:alpha:]]/*[[:alnum:]] does not match a/b -> FAIL
> > > [37] *[![:digit:]]*/[![:d-d] does not match a/b -> FAIL
> > > [38] *[![:digit:]]*/[[:d-d] does not match a/[ -> FAIL
> > >
> > >
> > > [ 0] *LIB* does not match lib -> OK
> > > [ 1] *LIB* matches lib -> OK
> > > [ 2] a[/]b matches a/b -> OK
> > > [ 3] a[/]b does not match a/b -> OK
> > > [ 4] [a-z]/[a-z] matches a/b -> OK
> > > [ 5] * does not match a/b -> OK
> > > [ 6] *[/]b does not match a/b -> OK
> > > [ 7] *[b] does not match a/b -> OK
> > > [ 8] [*]/b does not match a/b -> OK
> > > [ 9] [*]/b matches */b -> OK
> > > [10] [?]/b does not match a/b -> OK
> > > [11] [?]/b matches ?/b -> OK
> > > [12] [[a]/b matches a/b -> OK
> > > [13] [[a]/b matches [/b -> OK
> > > [14] \*/b does not match a/b -> OK
> > > [15] \*/b matches */b -> OK
> > > [16] \?/b does not match a/b -> OK
> > > [17] \?/b matches ?/b -> OK
> > > [19] \[/b matches [/b -> OK
> > > [20] ??/b matches aa/b -> OK
> > > [21] ???b matches aa/b -> OK
> > > [22] ???b does not match aa/b -> OK
> > > [23] ?a/b does not match .a/b -> OK
> > > [24] a/?b does not match a/.b -> OK
> > > [25] *a/b does not match .a/b -> OK
> > > [26] a/*b does not match a/.b -> OK
> > > [27] [.]a/b does not match .a/b -> OK
> > > [28] a/[.]b does not match a/.b -> OK
> > > [29] */? matches a/b -> OK
> > > [30] ?/* matches a/b -> OK
> > > [31] .*/? matches .a/b -> OK
> > > [32] */.? matches a/.b -> OK
> > > [33] */* does not match a/.b -> OK
> > > [34] *?*/* matches a/.b -> OK
> > > [35] *[.]/b matches a./b -> OK
> > > [39] *[![:digit:]]*/[![:d-d] does not match a/[ -> OK
> > > [40] a?b matches a.b -> OK
> > > [41] a*b matches a.b -> OK
> > > [42] a[.]b matches a.b -> OK
> > > [43] *a* matches a/b -> OK
> > > [44] *a? matches ab/c -> OK
> > > [45] a? matches ab/c -> OK
> > > [46] ?*/? matches a/b -> OK
> > > [47] */? matches /b -> OK
> > > [48] **/? matches /b -> OK
> > >
> > >
> > > Bye
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
