Re: Broken makefile given Autoconf version mismatch

[Keith Marshall]

On Sunday 16 April 2006 1:41 pm, Andreas Schwab wrote:
> 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

This requirement is reflected in the SunOS man page, (from SunOS 5.5.4, 
IIRC), to which I alluded earlier; that also mandates that directives be 
separated by newlines, and *not* by semicolons.  Even GNU's own info 
manual doesn't formally document this usage, although there is anecdotal 
evidence of its use in examples.

The thread I cited earlier does seem to be missing any record of the 
ultimate resolution of the reported problem.  Yes, as you note, the 
problem was initially perceived to be caused by missing semicolons; 
however, it persisted, even after those semicolons were inserted.  It was 
ultimately resolved only when this:

    sed 's/^.* \([^ ]\+\)$/\1/;1q'

was rewritten as:

    sed -e 's/^.* \([^ ][^ ]*\)$/\1/' -e '1q'

I accept that there were two fundamental changes introduced here, namely 
the elimination of the semicolons, and also the elimination of the \+ 
regex construct, and that either of these alone may have been sufficient 
to resolve the problem; at the time, we decided to remove *both* 
constructs, because *neither* is specified by POSIX, and therefore *both* 
are to be considered non-standard.

By all means bury your head in the sand if you wish -- I simply wanted to 
raise awareness of a potential problem, which we had encontered on 
another project; I remembered the potentially problematic syntax when I 
saw it in an earlier post in this thread, and thought you you might like 
to know about it.

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. :-)

Regards,
Keith.