It is also how glob works in other languages, such as perl python and
go, if that is seens as more relevant.
However, only some of them have escaping, instead [*] would be used to
match a literal *. I can remove the \, but then [ is more needed.
On Fri, May 13, 2016 at 4:38 PM, Per Hedbor <p...@hedbor.org> wrote:
> 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.
