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.