In message <[EMAIL PROTECTED]>, Ralf Wildenhues writes:
>> I enclose func_select below. Weaknesses:
>> 1. Newline after prompt. (Solving this portably seemed like too much work.)
>Grab the settings of ECHO_C, ECHO_N, ECHO_T from Autoconf, and use them.
ECHO_T? New on me.
I could probably do this, but wanted to keep this as small and self-contained
as I could.
>> func_select () {
>> func_select_args=0
>> if expr "$1" : "^[_a-zA-Z][_a-zA-Z0-9]*$" > /dev/null; then
>FWIW, expr expressions are always anchored, so there is no need for more
>anchoring (another instance below). But can't you avoid a fork here,
>like
> case $1 in
> [!_a-zA-Z]* | *[!_a-zA-Z0-9]*) usage "$1";;
> esac
Oooh, clever.
>'shift N' is not so portable.
I have been unable to find a living shell without it.
>Just drop the 1.
But yeah.
>> for func_select_arg
>> do
>> func_select_args=`expr $func_select_args + 1`
>> eval func_select_a_$func_select_args=\$func_select_arg
>> done
>This again forks a lot. I'd use a shell function to factor between
>$(()) and expr, so that only shells without the former use the latter
>and fork (Autotest and Libtool do this). Likewise below.
That's a thought.
>> if expr "$REPLY" : '^[1-9][0-9]*$' > /dev/null; then
>case $REPLY in
> 0* | *[!0-9]* ) bad ... ;;
>esac
Very clever.
I had not thought of the use of [!foo] as a replacement for a regex [foo]*.
... And I also didn't realize (though I should have) that spaces were allowed
in case patterns. I think I was thrown off by
case a in
x y) ;;
esac
But of course, spaces around | are probably sane. Neat!
-s
