Re: strange glob expansion

Re: strange glob expansion

[Sven Wischnowsky]

Peter Stephenson wrote:

> By the way, does anyone want a globbing flag to turn on extended glob?
> e.g. (#x)foo and (#X)foo would compile pattern foo with extended glob
> on or off.

That would then be an exception in that it is recognised even if
extendedglob is not set, right?

Hm, dunno. May make things hard to read if you are used to using
extendedglob, I think. Although it sounds like something that may be
useful, although I can't come up with an example.


However, this reminded me...

We had this discussion about allowing back-references. Personally I
don't think that just storing the matched portions in some special
array is the best way -- what if I'm really interested in the indexes
(beginning/end of matched part)?

So how about a set of globbing flags that turn on collecting
back-references, say what information we want and give the name of an
array where that information is stored? Something like `(#mparts)...'
to store the matched parts in an array named `parts', `(#pbegs:ends)...'
to store the begin-positions in an array `begs' and the end-positions
in an array `ends'. Or something like that.

I don't know enough about the matching code to know if this `turn-on-
back-references-only-when-needed' is possible and easy enough to
implement and if the effect on the normal, non-collecting processing
is small enough (in terms of execution speed).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: strange glob expansion

[Peter Stephenson]

Sven Wischnowsky wrote:
> Peter Stephenson wrote:
> 
> > By the way, does anyone want a globbing flag to turn on extended glob?
> > e.g. (#x)foo and (#X)foo would compile pattern foo with extended glob
> > on or off.
> 
> That would then be an exception in that it is recognised even if
> extendedglob is not set, right?

Yes, that's ugly.  There's no real reason why you'd use parentheses
without extendedglob for such a pattern, but the special case is not
nice.

> Hm, dunno. May make things hard to read if you are used to using
> extendedglob, I think. Although it sounds like something that may be
> useful, although I can't come up with an example.

I was thinking of the command line for people who don't usually use
extendedglob, but that's probably not a very likely usage.  Setting
extendedglob locally in functions is certainly to be preferred,
although sometimes you want to keep the user's setting while having
your own extendedglob patterns (as in completion).

> We had this discussion about allowing back-references. Personally I
> don't think that just storing the matched portions in some special
> array is the best way -- what if I'm really interested in the indexes
> (beginning/end of matched part)?
> 
> So how about a set of globbing flags that turn on collecting
> back-references, say what information we want and give the name of an
> array where that information is stored? Something like `(#mparts)...'
> to store the matched parts in an array named `parts', `(#pbegs:ends)...'
> to store the begin-positions in an array `begs' and the end-positions
> in an array `ends'. Or something like that.

Hmm, I was hoping to keep the globbing flag syntax compact and easy to
read.  We could have the array names fixed, to $match, $beginning and
$end for example, but use the letters (#mbe) to decide which would be
set, maybe also (#MBE) for setting MATCH etc. to the whole matched
string for use in substrings.  The arrays wouldn't have to be special,
though, so you could make them local.  This sort of arrangement
(although using functions) seems to work OK in emacs.  Can you think
of examples where using the same variable names for different matches
would cause a problem?

For substitutions in ${.../../..${match[1]}..} this would mean
delaying singsub() of the replacement string, and with global
substitution re-substituting the replacement string on each loop.  I
think that's OK, although it could make quite a difference when
substituting on arrays.  That was one advantage of using some special
syntax like \1 for backreferences: it's easy to detect when they're
being used.

> I don't know enough about the matching code to know if this `turn-on-
> back-references-only-when-needed' is possible and easy enough to
> implement and if the effect on the normal, non-collecting processing
> is small enough (in terms of execution speed).

There is some overhead with backreferences active --- each `(' and `)'
uses another subroutine call --- but the speed overhead is essentially
nil when not using backreferencing --- the fact that the size of the
struct changes when using backreferences can be avoided, too; that was
inherited from the Specner code, but in our case we don't need to
store the extracted matches inside the struct.  It looks like I can
even do it with the normal grouping effect of globbing flags, i.e. you
can turn it on and off in the middle, still with no significant
overhead (so if you're not using it, the only difference is the odd
extra test for the flags and zeroing things).

I suppose it's potentially worth having backreferencing even with file
globs for use with the e glob qualifier.  That means retaining the
number of the parenthesis over the entire filename path.

By the way, I'm not planning on removing the limit of 9
backreferences.  I think that ought to be sufficient.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy

Re: strange glob expansion

[Peter Stephenson]

Adam Spiers wrote:
> No, I was after all Perl modules starting with `L' in the sense that I
> would say that Text::Abbrev started with `T' rather than `A'.  (I
> later replace all `/' in the result of the expansion with `::'.)  So I
> did mean L**/*.pm, not **/L*.pm.  However, as Bart rightly guessed,
> L{*/**/*,}.pm was a load of rubbish.  I actually meant L*{/**/*,}.pm.
> Is there a better way of achieving this?

You could try generating all of them and exclude the wrong ones (with
extendedglob).  It's slower because it examines directories not
beginning with L (all of them), but it's a single pattern.  You can
stick in the ::'s at the same time.
  print **/*.pm~[^L]*(:gs./.::.)
I can't think of a better way of doing it as a single pattern.  With
the other way, you might want to put (N) at the end, although having
cshnullglob is a bit neater here.

By the way, does anyone want a globbing flag to turn on extended glob?
e.g. (#x)foo and (#X)foo would compile pattern foo with extended glob
on or off.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy

Re: strange glob expansion

[Bart Schaefer]

On Sep 6,  2:25pm, Peter Stephenson wrote:
> 
> By the way, does anyone want a globbing flag to turn on extended glob?

I've occasionally wanted a way to turn it *off* but that's mainly because
I have some shell functions (wrapped in "noglob" aliases) that accept glob
patterns as arguments and then expand them, and it's sometimes tricky to
get the quoting right if I want to match a file with a '#' in its name or
some such.  (Programmers are used to avoiding the more usual shell metas,
so I seldom have to match files containing '*' or '?'.)

I don't recall ever wanting to turn it *on* in a context where I couldn't
do so with setopt.