Re: extension of file-test primitives?

[L A Walsh]

Chet Ramey wrote:
> [this would] create an incompatibility between
> the shell's builtin test and a test binary. That incompatibility would be
> almost impossible to resolve.
>   
----
   Agreed.  So I agree that limiting this to use with '[['
would be a better choice that would eliminate such problems.

(reordered this to be first so I could 'reword' following
examples for clarity)

> On 8/19/17 8:30 PM, L A Walsh wrote:
>   
> > Curious, but how difficult or problematic would it be
> > to allow using brace-expansion (ex. {f,x} ) as a short-hand
> > to test/combine file-op tests like allowing:
> >
> >   [[ -{f,x} /bin/ls ]] && ...
> > or
> >    if [[ -{f,x} $file ]]; then ... ; fi
> >
> > instead of:
> >
> >   [[ -f /bin/ls && test -x /bin/ls ]] && ...
> >     
>
>   

Regarding:
> ... changing the established meaning of brace expansion,
----
   On a conceptual level, brace expansion expands
a string like '[[\ -{f,x}\ /bin/ls\ ]]' to:

 [[ -f /bin/ls ]] [[ -x /bin/ls ]]

I wasn't thinking of the current brace expansion routines
changing to implement this, but only in adding a new file-op
meta test -{X,Y[,Z[,...]]} that allows existing file operators
to be used in place of X, Y, Z.  This meta-op would only
be added to '[[' to avoid equivalent syntax expectations
out of external binaries.

As an example of conceptual equivalence of brace-expansion
in the two cases, this already works, using the standard
meaning for brace expansion (line numbers added for
ease of reference):

1) eval "
2)    [[ -"{f,x}" /bin/ls ]] &&
3)       :" &&
4)        ...(true case)...

For use as a file-op in a conditional test,  operator I was suggesting
removing lines 1 & 3 and the quotes, leaving

2)   [[ -{f,x} /bin/ls ]] &&
4)       ...(true case)...

The brace expansion would function, conceptually, the same (even
though I'm not envisioning the implementation being done through
a modification of brace expansion).