Re: Broken makefile given Autoconf version mismatch

[Keith Marshall]

On Sunday 16 April 2006 7:36 pm, Stepan Kasal wrote:
> Second, let me remind me that we are currently in a freeze; I believe
> that this type of changes should be put off after 2.60, unless it is
> supported by a real-world problem report.

I wasn't suggesting that you should immediadely rush to change anything; 
I was simply alerting you to an apparently related problem we had 
encountered in groff, which you might like to bear in mind, for future 
reference.

> > > > [...]  the use of semicolons as command separators in the sed
> > > > script is an implementation dependent extension, which is not
> > portable.
> >
> > > Is there any evidence that there exists a sed implementation that
> > does > not support the semicolon as command separator?  Note that the
> > thread > you quote above is _not_ about semicolons being unsupported,
> > but rather > about missing ones.  Autoconf is using semicolons in sed
> > expressions > already for many years (eg in the AC_OUTPUT_FILES
> > macro).
> > 
> > Let me turn that around, and ask if you can provide any documentary
> > evidence, other than anecdotal, to suggest that this use of
> > semicolons *should* be supported?  SUSv3 *expressly* demands that sed
> > directives be separated by newlines:
> > http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html
>
> The link contains the following text:
> | Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
> | followed by a semicolon, optional <blank>s, and another command verb.
> | However, when the s command verb is used with the w flag, following
> | it with another command in this manner produces undefined results.

Ah, I overlooked that, sorry.  Yet that is not reflected in my SunOS man 
page, which explicitly demands that *all* commands, in a multiple command 
sequence are separated by newlines; thus, SunOS 5.5.4 does not promise 
this level of POSIX compliance, (but I suspect that it does provide it).

> which means that the above code would be portable.

Indeed it should be; perhaps the Mac OS X implementation, on which the 
original problem was observed, lacks the appropriate level of compliance. 
Or, perhaps it was the \+ construct which was the real cause of the 
problem; I don't have access to such a system to verify this.

> But looking to the text, you can see that its distinction between
> functions and commands implies that semicolons cannot be used inside
> curly braces, so you have to write, for example:
>
> sed '/datarootdir/{
>         p
>         q
>     }'

And indeed, that is explicitly stated in the reference text.

> IIRC, Autoconf was recently fixed to obey this rule, even though I
> don't think a platform was found which wouldn't handle
>         sed '/datarootdir/{;p;q;}'

Yet the reference document expressly forbids that, for `{' is one of 
those commands which is *not* permitted to be followed by semicolon and 
another command.

> So we really don't ``bury our heads in the sand'' when we notice that
> we are depending on a feature which is not promised by POSIX.

Perhaps that was an unnecessarily harsh criticism, sorry.

> (BTW, note that
> sed '/datarootdir/{p
> }'
> is correct according to POSIX, ...

Are you sure about that?  After all `{' and `p' are documented as two 
distinct commands, and since `{' cannot be followed by semicolon and 
another command, they should surely need a newline to separate them.

> ... yet I think some implementations are not
> able to parse it.)

Which arguably, would be POSIXly correct behaviour.

> > Oh, and yes, I do know of at least one sed implementation which
> > definitely does not support the use of semicolons as command
> > separators; however, since it is one I wrote myself, for bare
> > standard MS-DOS, running entirely in the real mode 640kB address
> > space, it probably doesn't carry much weight in this context. :-)
>
> Is this the only missing feature for full POSIX conformance?  :-)

Oh, I wouldn't claim POSIX compliance for it; after all MS-DOS isn't a 
POSIX compliant OS.  At the time I wrote it, I needed a sed like program 
which could run on MS-DOS, on an original 8088 PC, (yes 8088 4.7MHz 
vintage PC).  I modelled it on the sed command description in the Waite 
Group's `UNIX System V Bible', published by Howard Sams; IIRC it was a 
fairly complete implementation, in terms of its command set.  It also 
included a reasonable implementation of a regex parser for basic regular 
expressions,  lacking only the `\{m,n\}' feature, I believe, (and that 
probably wouldn't have been too difficult to add, had I a need and the 
inclination to do so).

Regards,
Keith.