* Numeric range bug @ 1999-07-28 12:25 Peter Stephenson 1999-07-30 9:27 ` Pattern matching Andrej Borsenkow 0 siblings, 1 reply; 3+ messages in thread From: Peter Stephenson @ 1999-07-28 12:25 UTC (permalink / raw) To: Zsh hackers list Just discovered this. It will have to wait to be fixed --- it's been around for years and no-one's complained. I'm planning a rewrite of the pattern matching code anyway. --- Etc/BUGS~ Fri Jul 9 09:30:19 1999 +++ Etc/BUGS Wed Jul 28 14:22:29 1999 @@ -44,3 +44,7 @@ such patterns unchanged if they do not match regardless of the state of the nonomatch and nullglob options. ------------------------------------------------------------------------ +Numeric ranges are still too greedy with using characters; for example, +<1-1000>33 will not match 633 because the 633 matches the range. Some +backtracking will be necessary. +------------------------------------------------------------------------ -- Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy ^ permalink raw reply [flat|nested] 3+ messages in thread
* Pattern matching 1999-07-28 12:25 Numeric range bug Peter Stephenson @ 1999-07-30 9:27 ` Andrej Borsenkow 1999-07-30 9:29 ` Peter Stephenson 0 siblings, 1 reply; 3+ messages in thread From: Andrej Borsenkow @ 1999-07-30 9:27 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list > > Just discovered this. It will have to wait to be fixed --- it's been > around for years and no-one's complained. I'm planning a rewrite of the > pattern matching code anyway. > Just using the occasion. I once suggested to replace ad hoc code with conversion to standard regexps. I believe, now a days all systems have standard POSIX regexps available. This will be much more clean and I hope faster. Zsh patterns are pretty close to normal regular experssions so it should be not a problem (even SAMBA takes this course for wildcard matching :-) Just some points: - currently code scans pattern for every match. This may really be inefficient for globbing (even more so, as code has to dequote string every time). Using rgexps pattern can be compiled once - for recursive globbing quite a gain. - this may automatically solve the original problem of this post. Regexps are required to match the longest string, even if every subregexp is not the longest one. regards /andrej ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Pattern matching 1999-07-30 9:27 ` Pattern matching Andrej Borsenkow @ 1999-07-30 9:29 ` Peter Stephenson 0 siblings, 0 replies; 3+ messages in thread From: Peter Stephenson @ 1999-07-30 9:29 UTC (permalink / raw) To: Zsh hackers list "Andrej Borsenkow" wrote: > Just using the occasion. I once suggested to replace ad hoc code with convers > ion > to standard regexps. I believe, now a days all systems have standard POSIX > regexps available. This will be much more clean and I hope faster. Zsh patter > ns > are pretty close to normal regular experssions so it should be not a problem > (even SAMBA takes this course for wildcard matching :-) I don't think zsh is close enough to be able to do this, even without the possible vagaries of pattern matching on some of the machines zsh supports. I'm converting some existing regexp code (it's Henry Spencer's, which has a relaxed copyright) which should do this more smoothly, keeping pretty much all of the existing behaviour. > Just some points: > > - currently code scans pattern for every match. This may really be > inefficient > for globbing (even more so, as code has to dequote string every time). Using > rgexps pattern can be compiled once - for recursive globbing quite a gain. The current system *does* compile patterns. The complete path for a glob pattern is stored in a struct complist, and each segment in a struct comp, which is also used for standard patterns; each pattern is compiled only once every time it is encountered. Maybe you mean there's no easy way of duplicating patterns for future use, which is true, but there's currently no real application for that since patterns have to be recompiled separately for each command line after expansion anyway. When I've finished, the code will all be in a single string, so can be duplicated in one go, but I still don't how this can easily be used. You could cache simple patterns, those which previous expansions (parameter, etc.) don't change, and use the cached programme inside a function, but that's already a lot of work to do properly. > - this may automatically solve the original problem of this post. Regexps ar > e > required to match the longest string, even if every subregexp is not the long > est > one. Yes, but there's no equivalent for numerical matches in normal regexps, nor any obvious way that I can see of telling a regexp how to match a numeric range at all without some immensely complicated pattern. That's why I think the only solution is to write an ad-hoc pattern matcher, but do it properly. The rough basics are already working. Globbing flags are going to be harder to fit in --- but these would be quite impossible to do with a standard regexp matcher anyway, particularly approximate matching. -- Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1999-07-30 10:01 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-07-28 12:25 Numeric range bug Peter Stephenson 1999-07-30 9:27 ` Pattern matching Andrej Borsenkow 1999-07-30 9:29 ` Peter Stephenson
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).