Re: improving "~" builtin ?!

Re: improving "~" builtin ?!

[Byron Rakitzis]

The nice thing about rc pattern matching is that it is (with the
exception of files beginning with '.', of course) identical to the
filename expansion rules. In fact, the matching is implemented by
the same subroutine! Even if it is difficult to express the "strncmp"
concept with the ~ builtin, I think it would be a mistake to twist
the meaning of ~ to fit this requirement.

Re: improving "~" builtin ?!

[Rich Salz]

I think it's a bad idea and adds lots of complexity for no general-purpose
gain.  For example:
	~ 2 foo.yacc [fg]oo* *.yacc
Does the first pattern become "[f" or is the 2 the number of pattern
tokens so that it becomes "[fg]o"?  If the first, then the pattern doesn't
match; if the second, then it does match.  Confusing, and requires
introducing a new concept "the pattern match token".

What about the second pattern -- it becomes "*."  When compared with "fo"
it now fails!  Counter-intuitive.  If strcmp succeeds you expect strncmp
to succeed.
	/r$

Re: improving "~" builtin ?!

[malte]

I'd like to extend "~" in a way that it compares

	~ subject patern pattern ...

by at most n characters, as does strncmp (3) with its first to arguments.
Now I ask for your opinion if that makes sense, or if not, what you'd
propose to do instead.

_______________________________________________________________________________
malte@techfak.uni-bielefeld.de

send mail reply to:	Universitaet Bielefeld, Technische Fakultaet
		z. Hd. Malte Uhl
		Postfach 8640
		4800 Bielefeld 1

improving "~" builtin ?!

[malte]

What do you think about adding a numeric option to rc '~' builtin?
It should change the semantics from strcmp -> strncmp.


_______________________________________________________________________________
malte@techfak.uni-bielefeld.de

send mail reply to:	Universitaet Bielefeld, Technische Fakultaet
		z. Hd. Malte Uhl
		Postfach 8640
		4800 Bielefeld 1