Well. Is [ and \ really that common in glob patterns? (the addition of
quoting and making [ a control character being the incompatible
changes)
It is possible to use 8.0::glob (not yet in place).
Or this, which is future compatible (8.0:: would be removed after a while):
add_constant( "glob", lambda(array|string a, array|string b) {
array(string)|string compat(array|string what) {
if(arrayp(what)) return map(what,this_function);
return replace(what, (["\\":"\\\\", "[":"\\[" ]));
};
return !!glob(compat(a),b);
});
(since I don't think any of the array version are used in roxen, it
can be simplified a bit.. :))
Anyway, the glob function in 8.1 complies with the definition of glob
in wikipedia, whatever that is worth.
As for why glob was modified:
The lack of quoting made it impossible to match * or ?.
The [ is less important to me at least, I just added that to be
feature complete (or, well, to the 'basic' glob pattern syntax).
After perusing the roxen source there are very few locations where the
pattern is not a simple constant *.<ext>, only a few places takes the
pattern as input from the user (web developer). In most cases this
seems to then be matched to a mime type ([ and \ being somewhat
uncommon in those) or a file (not path) name (no \, theoretically [
can occur),
Of course, custom code can do whatever.
On Fri, May 13, 2016 at 4:10 PM, Jonas Walldén @ Pike developers
forum <10...@lyskom.lysator.liu.se> wrote:
> Just saw Per's checkin (781fcde2) in 8.1:
>
> > Extended glob pattern syntax:
> > o \ can now be used to quote special characters in the pattern
> > o [ can be used for ranges of characters ([bx] [a-c0-9] [^a] etc).
> >
> > Also changed glob to return the matching glob instead of 1 when an
> > array is passed as the first (pattern) argument.
> >
> > This can be used to remove some loops where you want to do
> > different things depending on which pattern matched.
> >
> > Both these changes are incompatible.
>
> Can we please put this in a new method or use opt-in with an extra
> flag? I'm not too worried about the return value, but the changes in
> glob parsing sound problematic to me.
>
> At least for our customers there are plenty of globs in user data
> (RXML code, system configs, custom modules etc) that could misbehave
> silently, i.e. without producing compile-time errors.
