* Re: strange glob expansion
@ 1999-09-06 12:43 Sven Wischnowsky
1999-09-06 14:08 ` Peter Stephenson
0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 1999-09-06 12:43 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: strange glob expansion 1999-09-06 12:43 strange glob expansion Sven Wischnowsky @ 1999-09-06 14:08 ` Peter Stephenson 0 siblings, 0 replies; 4+ messages in thread From: Peter Stephenson @ 1999-09-06 14:08 UTC (permalink / raw) To: Zsh hackers list 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <19990905220731.A7232@thelonious.new.ox.ac.uk>]
* Re: strange glob expansion [not found] <19990905220731.A7232@thelonious.new.ox.ac.uk> @ 1999-09-06 12:25 ` Peter Stephenson 1999-09-07 19:44 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Peter Stephenson @ 1999-09-06 12:25 UTC (permalink / raw) To: Zsh hackers list 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: strange glob expansion 1999-09-06 12:25 ` Peter Stephenson @ 1999-09-07 19:44 ` Bart Schaefer 0 siblings, 0 replies; 4+ messages in thread From: Bart Schaefer @ 1999-09-07 19:44 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-09-07 19:45 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-09-06 12:43 strange glob expansion Sven Wischnowsky 1999-09-06 14:08 ` Peter Stephenson [not found] <19990905220731.A7232@thelonious.new.ox.ac.uk> 1999-09-06 12:25 ` Peter Stephenson 1999-09-07 19:44 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).