Re: extension of file-test primitives?

[L A Walsh]

Interesting....clever, even though not well vetted here, either.

Pierre Gaston wrote:
> You can use a loop, here is hack(ish) function that perhaps work (ie 
> not tested too much):
> testfile () {
>   local OPTIND=1 f=${!#}
>   while getopts abcdefghLkprsSuwxOGN opt; do
>     case $opt in
>       [abcdefghLkprsSuwxOGN]) test -$opt $f  || return 1;;
>       *)return 1;;
>     esac;
>   done
>  }
> if testfile -fx file;then.
----
However, I am not wild about the way it creates use of
two character tests (-ge) that I, Chet and Greg don't
like due to confusion with existing infix operators.
It's more likely to create maintenance problems just based
on that attribute alone.

I also don't like having to split it apart from other '[['
operators. 

FWIW, I always use '[[' ... ']]', if for no other
reason than not having to use quotes, as well the consistency
of using '&&' and '||' that test and '[' can't use.

Trying to remember that something like:
  > a=1 b=2; test 1 == $a && 2 == $b && echo hi
  -bash: 2: command not found
doesn't work wastes time, as well as
  > a=1 b=2; test 1 == $a -a 2 == $b && echo hi
not working with '[[', where in changing to '[[':
  > a=1 b=2; [[ 1 == $a -a 2 == $b ]] && echo hi
  -bash: syntax error in conditional expression
  -bash: syntax error near `-a'

Even parens need special handling, outside of '[['.

I'd also have to remember to change the conjunction ops. I.e.
changing "-a" to '&&':
  > a=1 b=2; [[ 1 == $a && 2 == $b ]] && echo hi

The [[ operator can be seamlessly changed to numeric ops:
  > a=1 b=2; (( 1 == $a && 2 == $b )) && echo hi

A lot of special casing when updating such usage, as well
as it not being readily combinable in [[...]] with other
tests.

The idea was to add a way to allow a shorthand that wouldn't
require secondary knowledge (what does testfile do), or
a need for including it.