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.
