At 2023-04-16T16:39:27+0200, Bruno Haible wrote: > Ralph Corderoy asked: > > > When I run > > > > > > pdfinfo doc/automake.pdf | tr -d '\000' | grep "Page *size" | sed -e > > > 's/Page *size: *\\([[:digit:].]*\\) *x *\\([[:digit:].]*\\).*$/\ > > > .nr pdfpic*width (p;\\1)\\n\ > > > .nr pdfpic*height (p;\\2)/' > > > > Are you running those three lines in a shell or have you edited the > > troff to be that text? IOW, is troff filtering the text before sh > > sees it? > > I was doing these experiments in a shell. How it works within troff > and with .ec, I don't know and did not test.
I think that:
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.
3. I agree with Ralph that using grep as a simple filter, when sed is
already required subsequently, is wasteful.
So this is not only a real bug, a portability problem, and inefficient,
but it has been for quite some time, affecting groff 1.22.4 as well.
I've filed Savannah #64061 about this.
Oh, and it also turns out that:
4. Solaris sed does not recognize POSIX character classes in its
regular expressions. So '[:digit:]' has to go.
I see some further sed-related notices in the HACKING file in my future.
I approve of the handful of features GNU sed added, but it is _way_ too
tolerant in what it accepts. It should smash the user's fingers with a
diagnostic hammer if they wander off the path.
pdfinfo isn't installed on gcc211.fsffrance.org, but it was easy enough
to simulate its operation to test my changes.
The attached "newpdfpic.sh" works on both Solaris 11 and macOS 12. And
on GNU/Linux, too, of course.
One thing I would point out is that we can still use input line
continuation in *roff input (and with the backslash as the escape
character), since the `.ec @` request only takes place _within a macro
definition_). In copy mode, the \newline escape sequence is elided as
it is read.
Comments?
Regards,
Branden
[1]
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=9d885c6b342f71594af5d45f37ce65c121641e25
The reader must sift through the numerous unrelated changes...
[2] '\n' _is_ meaningful on the matching side of a sed 's' command,
where it is essential for multiline matches, a journeyman technique.
newpdfpic.sh
Description: Bourne shell script
signature.asc
Description: PGP signature
