Re: [PATCH] m4sh: always re-exec with $CONFIG_SHELL, if it's set

[Stefano Lattarini]

Hi Paul, thanks for the quick reply.

On Tuesday 08 November 2011, Paul Eggert wrote:
> On 11/08/11 03:02, Stefano Lattarini wrote:
> > I see that this patch might raise some questions, and some of its
> > effects can indeed be debatable; and anyway, it certainly leaves ample
> > room for improvement.
> 
> Could you elaborate a bit on that?
>
Yes (and sorry for the curtness, I'm in bit of a hurry right now):

 1. With this patch, not only configure will always re-execute itself with
    $CONFIG_SHELL when that is set (which I think is good BTW, otherwise I
    wouldn't have sent the patch ;-) --- *all* the m4sh-generated scripts
    will do the same as well.  This is probably an overkill, and might be
    undesirable under certain conditions (or simply for the tastes of some
    prospective m4sh clients).

 2. There is currently no documented way to prevent this re-execution;
    in the long run, it would be nice to offer possibility for overrides
    (the user is always right!), both "global" (with an environment
    variable probably -- CONFIG_SHELL_NO_REEXEC? or M4SH_NO_REEXEC?)
    and "local" (an ad-hoc "early" option for configure maybe, say
    `--no-reexec'?).

 3. The current implementation of _AS_DETECT_BETTER_SHELL probably does
    too much; see the "FIXME" comment my patch introduces:
     # The real workhorse for detecting a shell with the correct features.
     # FIXME: this should be split into two macros, one to detect a better
     #        shell, and one to re-execute with it.

 4. For generic m4sh clients, we shold probably use a "more proper"
    name than `CONFIG_SHELL' for the environment variable that holds
    the shell deputed to re-execute the script (ok, this is more of
    a "wishlist" item rather than an issue).

> I'd rather avoid a branch if I could,
>
Why?  That is the best way to keep the work public and going, without 
risking to destabilize the code base.

> and just install it, but would like to know its effects and
> shortcomings first.
>
That's why we should have a separate branch :-)

> (Evidently nobody has had the time to review it carefully,
> but if we had started a branch every time *that* had happened,
> Autoconf would have thousands of branches by now. :-)
> 
Don't get me wrong -- my branching proposal wasn't due to the "slowness"
of the review (it has been only a week BTW, I'm not *that* impatient ;-),
but rather to the possible issues that have occurred to me between my
first message and the ping (issues which I've reported above).

Thanks,
  Stefano