Re: maybe feature, but still confusing...

[Linda Walsh]

Linda Walsh wrote:

> Was trying a combo if statement with normal [[]] eval and an arith
> exp.
>
> in my ENV, (chose a number var at random), LINES=66
>
> So:
>  echo "LINES=$LINES"
>  LINES=66
>  if [[ -z "" && ((LINES == 66 )) ]]; then echo foo; fi
>  foo
>
> But:
>  if [[ -z "" && ((LINES < 80 )) ]]; then echo foo; fi
> (prints nothing)....
>
> What am I missing?
----


I did find a a work around, even it it is a bit more verbose:

if ( [[ -z $dev1 || -z $dev2 ]] || ((dev1==0||dev2==0)) ); then echo not good; fi 

(and another quirky looking one:
  if test -z $dev1 -o -z $dev2 || ((dev1==0||dev2==0)) ; then echo not good; fi
note you can't use the same type of "or" operator...I'm sure bean-counting
code-managers would LOVE that syntax...but it IS Shell, so....they can't 
complain
too much!)...

I.e. 
setting
dev1=1 dev2=2 before either works
but 
dev1=1 dev2=0, prints 'not good'...

Just guessing but it's yet another 'special' case exception
to things inside of [[]] not working as expected...
(like the [[ "$a" =~ "two[ ]*words" ]] fiasco and having no way to group an
RE w/spaces...(other than first putting it in a var))

At least I understand that one now, though still don't agree with having 
no way to group an RE w/o using a var  -- even if it was something 'rare', 
like «double angle brackets».   

But the above if, isn't using quotes OR the =~, so there must be something
else going on...  Are mathematical evals/expressions not allowed inside
[[]]?   Was there a reason why that was considered