Approximate matching

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 3, 12:22pm, Bruce Stephens wrote:
} Subject: Re: PATCH: 3.1.5 - (Sven) Case-insensitive globbing
}
} Approximate matching could either use the auto-correct code, or could
} use something like whatever agrep uses.  In the latter case, it would
} have an optional integer parameter too, so "(#a1)readme" would match
} "Readme" and "read.me", but to match "read", you'd need "(#a2)readme".
} 
} Hmm, maybe this could provide a way to configure the autocorrection
} feature too?

On Nov 3,  3:01pm, Zefram wrote:
} Subject: Re: PATCH: 3.1.5 - (Sven) Case-insensitive globbing
}
} Maybe.  The autocorrection could be implemented as a shell function,
} which by default uses fuzzy globbing to generate corrections.  Is this
} what you have in mind?

I rambled on about this back in
	http://www.zsh.org/mla/workers/1996/msg01707.html
during a thread about tcsh-style correction (which can be invoked in a
completion-like manner).

It should be relatively simple to provide a completion interface to
spckword(), which could then be used as the default for this operation.
A fuzzy matching function could then be added as a user-defined widget
if desired (and spckword() made to call it, if we give it a predefined
widget name or some such).

On Nov 3,  8:09pm, Jarkko Hietaniemi wrote:
} Subject: Re: PATCH: 3.1.5 - (Sven) Case-insensitive globbing
} 
} It so happens that I have been slowly implementing from scratch the
} approximate matching algorithm(s) used in agrep.  My intention has
} been to encapsulate them into a nice library. [...]

On Nov 3,  6:54pm, Zefram wrote:
} Subject: Re: PATCH: 3.1.5 - (Sven) Case-insensitive globbing
}
} I'm concerned about how it would be integrated into zsh's globbing code.
} I doubt that we can actually use an external library for fuzzy matching,
} at least in the cases where the glob pattern contains more than just
} literal text.  But others here should be able to give a more definitive
} opinion on this.

I don't know all that much about zsh's globbing code, but I've written
both globbers and regex packages and in general they don't mix well.  I
doubt, for example, that we want to convert glob patterns into regexes
to pass them through an agrep library; and globbing usually outperforms
regular expressions on very short strings like file names.

That isn't to say that the fuzziness algorithms wouldn't be adaptable,
but it limits the kinds of library interfaces would be useful to zsh.

On Nov 3,  9:36pm, Jarkko Hietaniemi wrote:
} Subject: Re: PATCH: 3.1.5 - (Sven) Case-insensitive globbing
}
} And I still can pull another joker from my sleeve: cdpath is
} definitely fiddling with the fs semantics :-)

No, it isn't; not any more than searching for executables in $PATH is.

Of course, I wouldn't say that ANY of the things (most elided) that were
mentioned in this little side-discussion are actually "fiddling with fs
semantics."  Ever heard of conditional symbolic links?  The Sony NeWS OS,
a BSD 4.4 derivative that I was running for a while many years ago, had
symbolic links that could change what they pointed at based on the value
of an environment variable.  THAT is fiddling with the fs semantics.  It
also is probably the biggest security hole anybody ever introduced into
any unix platform.

Having * match files in multiple unrelated directories is fiddling with
a universal unix shell globbing mechanism in a similarly dangerous way,
but it would have to be implemented by actually generating the paths to
any files not in the current directory.  If you passed the result to
"echo" you'd see those paths.  If there were some magical way to hide
the paths yet still have external commands access the files, THEN it
would be "fiddling with fs semantics."

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com