Re: [PATCH] configure: test shell parameter substring processing and possibly exec one

Subject: Re: [PATCH] configure: test shell parameter substring processing and possibly exec one

Date: Wed, 02 May 2012 19:25:53 -0300

To: Tomi Ollila, notmuch@notmuchmail.org

Cc:

From: David Bremner



I'm still a bit leery of over-complicating the configure script to
support legacy /bin/sh; however, I guess I'm at least convinced that the
only trivial solution is just to document the requirement for posix
/bin/sh.  It will be odd to back this out and document the restriction
later, so please chime in now if you have strong feelings either way.

Tomi Ollila <tomi.ollila@iki.fi> writes:

> To tackle this situation the beginning of configure attemts to do a silent
> parameter substitution in a subshell; in case this fails the subshell exits
> with nonzero value which is easy to detect.

s/attemts/attempts/

> The || constructs are used twice. The first one is used as Bourne shell
> chokes on 'if ! ... ' construct (and if ...; then :; else do_things; fi
> looks stupid). The second one(liner) takes care of the possible future
> addition of 'set -eu' in the beginning of this script.

OK, although I might have gone for the empty if myself.

> +# If not, attempt to locate and launch one which probably can.

> +( option=option=value; : ${option#*=} ) 2>/dev/null || {

option=option=value seems a little _too_ clever to me. Any reason not to
use e.g. 

option="A,B" 

> +    if test x"${_NOTMUCH_CONFIGURE-}" = x ; then
> +	_NOTMUCH_CONFIGURE=1; export _NOTMUCH_CONFIGURE

This could probably use a comment.

> +	for x in /bin/ksh /bin/bash /usr/bin/bash

I guess add /usr/local/bin/bash?  I'm slightly worried this list will
just keep growing.

Thread: