[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
correct behavior for output-comparison conditional?
From: |
Dave Kemper |
Subject: |
correct behavior for output-comparison conditional? |
Date: |
Thu, 8 Jul 2021 09:59:16 -0500 |
Groff troop,
I have a question concerning the comparison operator that seems to
have neither a name nor a symbol (in that it can be invoked using
nearly any character). It is documented in groff(7) as 's1's2' with
the defined truth value of "s1 produces the same formatted output as
s2." (This is a correction to the man page since 1.22.4, one of many
changes in commit 356bc65d.)
The info manual, in fact, has an example to show that this conditional
compares formatted output rather than input strings. This behavior is
in line with historical troff (although even CSTR #54 was unclear
about this).
But as Bjarni notes in http://savannah.gnu.org/bugs/?60836#comment1,
there are cases where this operator doesn't behave as documented, and
I'm trying to figure out whether this is a failure of the
documentation or of the code.
A simplified version of the example he posted there is:
.ie "ABC\h'2n'"ABC\h'4n'\h'-2n'" \{\
strings are the same
.\}
.el \{\
strings are different
.br
ABC\h'2n'D
.br
ABC\h'4n'\h'-2n'D
.\}
The two input strings:
ABC\h'2n'D
ABC\h'4n'\h'-2n'D
do produce identical output, which can be deduced from looking at the
strings and knowing how \h escapes work, and can be verified by
looking at groff's intermediate output via its -Z option: following
the respective strings' V commands, which each move to a different
line, the rest of the intermediate output is identical for both cases:
H72000
tABC
h10000
tD
Heirloom troff produces intermediate output different from groff's,
but Heirloom's output from both strings matches each other, differing
only in the vertical position (V) line:
H72000
V24000 [or 36000]
cA
h7220cB
h6670cC
h16670cD
Yet both implementations display "strings are different," indicating
that the nameless conditional in question does not think they produce
identical output.
This strongly looks like a bug, but the consistency across troff
implementations gives me pause. Is there some subtlety to the way
this comparison conditional is supposed to work that explains these
results?
- correct behavior for output-comparison conditional?,
Dave Kemper <=