Re: 01-as-require-shell-fn.patch

[Akim Demaille]

 >> I don't understand why you remove all this.  Plus, it looks broken.
 >> This is still wanted by AS_INIT which is expected to be asis.

 > _AS_LINENO_PREPARE is not reinvoking the shell; the difference between
 > AS_INIT and AS_INIT_WITH_SHELL_FN is that the latter exits if shell
 > functions are not found. 

I'm not sure whether you are referring to the present (after your
patch), or to the previous situation.  In the previous situation
AS_INIT did restart the shell to find LINENO support.

 > I took this path because AS_INIT_WITH_SHELL_FN tried to divert
 > AS_SHELL_SANITIZE on M4SH-INIT, so doing

 > $SHELL<<\_ASEOF
 > AS_INIT_WITH_SHELL_FN
 > _ASEOF

 > did not work.

AS_INIT *must not* play game with diversions.  AS_INIT_WITH_SHELL_FN
should not be different.  One reason is embedding scripts within
scripts.  And it is not "weird" or unusual: it is a requirement from
the start for config.status, which is embedded in configure.  If

 > $SHELL<<\_ASEOF
 > AS_INIT_WITH_SHELL_FN
 > _ASEOF

 > did not work.

then there is something that should be fixed.

This is why I had put so much emphasis on having both flavors of
AS_INIT, very close to each other except for the re-exec loop.


 >> Well this is still not what I said: AS_INIT no longer looks for LINENO
 >> support,
 >> 
 > Actually it did not -- the difference is that _AS_LINENO_PREPARE no
 > longer tries to find a better shell.

What do you mean?  Previously, AS_INIT did try to find a "better"
shell, with "better" being defined as "supports LINENO".  


Ahhh!  Now I understand our confusion: the picture I had of the code
is blurred.  Indeed, it is not AS_INIT that does everything, it is
AS_PREPARE.  So when I meant two flavors of AS_INIT, I actually meant
two flavors of AS_PREPARE :( And now I understand better your comment
about

 > $SHELL<<\_ASEOF
 > AS_INIT_WITH_SHELL_FN
 > _ASEOF

since actually, it is

 > $SHELL<<\_ASEOF
 > AS_INIT
 > _AS_PREPARE_WITH_SHELL_FN
 > _ASEOF

but the fact that this snippet (or the more correct one if I am still
wrong on the names (I don't have enough time to really re-read the
code)) must remains clear from diversion games remains true.  We must
allow means to embed scripts within scripts (even if it must some
slightly less natural code than for the outer script).

 >> But OK, let's go forward.
 >> 
 > Thank you very much.

Thanks to you!