On Wed, Aug 13, 2014 at 12:16:52PM -0400, Steve Simmons wrote:
>
> On Aug 12, 2014, at 4:36 PM, Chet Ramey <chet.ra...@case.edu> wrote:
>
> > On 8/9/14, 7:07 AM, Steve Simmons wrote:
> >
> >> It would be nice to have ganged file test switches. As an example, to test
> >> that a directory exists and is properly accessible one could do
> >>
> >> if [[ -d foo ]] && [[ -r foo ]] && [[ -x foo ]] ; then . . .
> >>
> >> but
> >>
> >> if [[ -drx foo ]] ; then . . .
> >>
> >> is a lot easier.
> >
> > Sure, but it's only syntactic sugar.
>
> Knew that going in :-). Other discussion points out how limited it is;
> I'm perfectly happy pulling back. My thoughts on how to do this more
> flexibly boil down to the capabilities gnu find has w/r/t file types
> and modes. Unfortunately we have a few systems which lack gnu find
> and are "vendor supported appliances" (eyeroll) and we're unable to
> add new software beyond simple scripts. Which also means that any new
> bash feature would probably be unavailable for years, so it's not like
> this is a big loss.
>
> If others have no interest in this syntactic sugar I see little point
> to adding it; a broader and more flexible solution is just to use find
> as above.
I like the idea, but switch negation would need to be supported, and
I don't think that's been covered sufficiently. Using ! as a switch
modifier might be possible, and I like it, but would then also apply to
single filetest switches, e.g., -!e foo would be the same as ! -e foo.
Maybe that's possible, but it seems a fairly major addition to the syntax.
Using caps for switch negation is pretty common, but the filetest switches
already use some uppercase values, so I don't think that's possible in
this case.
I'm a little confused about the 'before' example:
if [[ -d foo ]] && [[ -r foo ]] && [[ -x foo ]] ; then . . .
I thought that && could be used reliably within the [[ ]] construct,
including short-circuiting the tests, so this could be:
if [[ -d foo && -r foo && -x foo ]] ; then . . .
I don't see how the bundled switces could be ambiguous, so must be
missing something.
Ken
