groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: groff 1.23.0.rc4 on Solaris 11 OpenIndiana


From: G. Branden Robinson
Subject: Re: groff 1.23.0.rc4 on Solaris 11 OpenIndiana
Date: Wed, 19 Apr 2023 16:33:15 -0500

At 2023-04-17T04:29:47-0500, G. Branden Robinson wrote:
> 1.  The doubled backslashes inside the single-quoted sed expression
>     are unnecessary.  They would be required if the escape character
>     _hadn't_ been changed, but it was.  This solecism came in that way
>     with the first commit of pdfpic.tmac in August 2015.[1]
> 2.  The '\n' in the _replacement_ text of a sed expression is an
>     error.[2]  It was part of the same commit.

I have to retract this.  They are necessary.

But the reason is devilish.

I was really wondering about this because even the GNU sed Texinfo
manual, (as far as I can find) doesn't say it is possible for

s/foo/bar\nbaz/

to work to stick a newline into the replacement text.  But it is, and
macOS sed supports this, too.

And that's a damn good thing, as it turns out.

To fully understand the quoting issues involved in using *roff's `sy`
request, we have to understand that after the formatter interprets the
request's arguments, they become a C/C++ language character string that
is processed by a function that reads the argument byte by byte for
passage to the old C library system() function.  With no state tracking
of whether the previous byte seen was '\'.

If Bernd understood this, I wish he had explained it to the rest of us.

So I refactored this byzantine carnival to clarify the situation.  I
tested it on (Debian) GNU/Linux, macOS 12, and Solaris 10 and 11, the
last three via FSF France's compiler farm.

The change is attached, with (more) detailed explanation.

We still won't be able to support Solaris sed, in either its /usr/bin or
/usr/xpg4/bin forms.  Unless we change the way GNU troff processes `sy`
arguments, we will forever need a non-standard extension to sed(1) to
pull of this sort of tomfoolery.  (Or unless POSIX standardizes this
application of the '\', 'n' sequence in sed commands.  If they do, I
hope they apply it to 'a', 'c', and 'i' as well.)

But as it happens, changing GNU troff's `sy` handling coincides with
ideas I had years ago to enable GNU troff to open files with weird
characters in their names...

Regards,
Branden

Attachment: 64061.diff
Description: Text Data

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]