[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Generic mechanism to detect shell features
From: |
Eric Sunshine |
Subject: |
Re: [PATCH] Generic mechanism to detect shell features |
Date: |
Tue, 13 Jan 2004 11:04:17 -0500 |
On 12 Jan 2004 21:24:01 -0800, Paul Eggert wrote:
> 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.
That's a good point.
> 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.
Yes, eval seems like a good idea. Another option is to export the check to
an external file and use '.' to invoke it in a sub shell. For instance:
cat >conftest.inc <<_ASEOF
...function test...
_ASEOF
if ( . conftest.inc ) 2>/dev/null ; then
echo "ok"
fi
rm -f conftest.inc
I have run tests with the eval and the '.' technique, and they both seem
like winners. It seems that either one should work correctly.
-- ES
Re: [PATCH] Generic mechanism to detect shell features, Eric Sunshine, 2004/01/12