Re: extension of file-test primitives?

[L A Walsh]

Greg Wooledge wrote:
> They're not intended to work that way.  If you want to test f+x+s then
> you just make another function:
>
> -fxs() { test -f "$1" && test -x "$1" && test -s "$1"; }
>   
How many different single-ops?  over 20?  That's 20 factorial
combos.  You wanna include that in a script?  um...
> All of your syntactic proposals have problems.  First, curly braces.
> These already have their own semantics, and what you are proposing
> does not work with those semantics.  You proposed:
>
> [[ -{f,x} $file ]]
>
> With standard curly brace semantics (ignoring [['s stupid magic
> parser-bending rules for the moment) this expands to:
>   
----
   Nope.. can't ignore '[['s special rules.  That's why this
can work.
> Second, you proposed test -fx.
I did not -- that was PePa's idea which had nothing to do with
my proposal.  My initial design avoided that issue specifically for
that reason.   I spoke out against using a combined op like -ge
(as you would suggest for a function name) because it conflicts
with existing two character operators.

The rest of your argument against merged primitives like
funcs -ef, -fe... etc. applies to your using function names
with those names as well as PePa's idea.

The only form I proposed is -{X,Y,Z....} and after Chet pointed
out the compat probs with external 'test' binaries, I limited
to only being used with '[[' -- which has its own compat rules --
that being the reason I agreed w/Chet to limit it to use
with '[[' -- right Chet?  ;-)