Re: [PATCH] Generic mechanism to detect shell features

[Paul Eggert]

Eric Sunshine <address@hidden> writes:

> In other words, you can do the following without crashing the  
> currently running shell:
> 
>   if (run shell-function test) 2>/dev/null; then
>     # success
>   fi

Surely that won't work reliably with traditional shells that can't
even parse the contents of "run shell-function test".  I'd think that
if they can't parse the subexpression then they won't parse the
containing expression, and they may just give up on the entire script.

To take an extreme example, the following script is guaranteed to
print OK on a posix-conforming shell

if (case a in a) exit 0;; b) exit 1;; esac)
then echo ok
else echo fail
fi

But suppose we wanted to test for support for a 'case' statement on a
hypothetical shell that did not support 'case'.  The above statement
would not be a good way to test such a shell, since it wouldn't even
parse 'if' statement at all and would print a bunch of error messages
like "syntax error: `then' unexpected" and then might exit the script.

We'd have better luck with something like this:

if (eval '(case a in a) exit 0;; b) exit 1;; esac)') 2>/dev/null
then echo ok
else echo fail
fi

This would be far more likely to do the right thing, since any syntax
error would be well-protected inside a subshell, and would not be
parsed until the subshell is entered.

> It seems to me that the historic search order of attempting bash
> before ksh and zsh makes more sense,

Yes it does.  Let's not mess with the search order now.