Re: multiline output variables.

[Dan Manthey]

On Tue, 25 Jan 2005, Stepan Kasal wrote:

> > Rather than counting the delimiters to just _notice_ when an output
> > variable containing the delimiter would foul up the escaping mechanism, I
> > use it to instead modify the delimiter and redo the whole process.  It's
> > now guaranteed to always work, regardless of the contents of the
> > variables.
>
> I don't understand what you mean, and I haven't yet time to study your
> code.  (Sorry for that.)

No single delimiter is guaranteed to be in none of the output variable
values.  However, since they are all finite, there is guaranteed to exist
some string that is in none of them.  I try an unlikely delimiter
(suggested by Noah, I believe), check if it conflicts, and if it does,
choose a new one until there is no conflict.  In the usual case, this only
costs one extra sed invocation (I'm using a wacky sed script instead of
grep -c.) per fragment.

>
> But in my previous mail, I suggested a solution, based on Noah's idea,
> which was a combination of your cold approach and the traditional
> autoconf approach.
>
...
>
> And I think the code would be much cleaner this way than with all the
> hacking about delimiters.
>
> Do you agree with me?  Are you willing to incorporate it into your patch?
>

Well, this basically reduces the slowdown my original solution introduced,
but what I've now done removes it almost entirely (except the extra sed
per fragment mentioned above), so I don't see a need for it, and it just
makes things more complicated.  So no, I don't do it *grin*.

> > If indeed everybody uses these on lines by themselves, could we require
> > that?  This would have the advantage (perhaps small) that the newline
> > following the output variable could be deleted. [...]
>
> I think your reasoning is right.  So please implement this, too.
> Would you volunteer to sketch the manual changes, too?

Yeah.

>
> > Recursive output variable:
>
> You are right, the current inconsistent situation is irritating.
> I suggest that we do the replacements non-recursively (and document it).
>
> I think we could simply change the sed scripts from
>
> :t
> /@[a-zA-Z_][a-zA-Z_0-9]*@/!b
> s,@SHELL@,/bin/sh,;t t
> ...
>
> to
>
> /@[a-zA-Z_][a-zA-Z_0-9]*@/!b
> s,@SHELL@,/bin/sh,g
> ...

Nope.  That leaves a slightly different sometimes-recursive behavior.  It
now depends on the ordering of individual variables, rather than on
whether they're all in the same sed fragment.  Clearly unacceptible.

As I said, to remove recursion, we need an escape mechanism for things
that look like output variable references.  Since such things were already
broken, we can choose that pretty arbitrarily.  I'd say turn @foo@ into
@_!#foo#!_@ inside of output variable values, and then do a final step of
@_!#foo#!_@ -> @address@hidden  The problem with this is that any instances of
@_!#foo#!_@ that were supposed to be retained from the templates will also
be changed.  Seems pretty safe to me, but of course I'm open to other
suggestions for the escape.

Anyway, I agree that never recursing is better than always recursing,
since recursion can be done by hand in ./configure when it's really
wanted.  Also, yes, with no recursion, we can drop the `t t' stuff and use
s///g.

By the way, what are the practical limits to the size of line that can be
handled by sed.  Note that the point of multiline output variables is
generally to have several lines of code (though it's then likely there
won't be much else on the line), which could easily be 1-4k characters.  I
seem to recall that POSIX says sed has to handle 8k lines, but what about
reality?

> So I'd like to say again a big *thank you* for your work.  It's not bad,
> as an Englishman would put it.
>
> Are you willing to donate more work and incorporate my suggestions to your
> patch?

Ah shoot.  I have to check with my work as to giving this stuff out.
*grin* Perhaps it'll end up that you're just helping me and not visa
versa.  I'll get back to you on that.

-Dan