Follow-up Comment #11, bug #66481 (group groff):
commit 39c1176bfa9ba84d519b015b1453f316e013d1de
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date: Mon Jan 27 18:52:39 2025 -0600
[troff]: Fix Savannah #66686 (`\w|foo|` blues).
* src/roff/troff/input.cpp (is_char_usable_as_delimiter): Restore `|`
character as an invalid delimiter when not in compatibility mode.
This would regress the fix for Savannah #66481, but...
(do_overstrike, do_bracket, do_name_test, do_zero_width_output)
(read_size, do_register, do_width, do_device_extension)
(read_drawing_command): Throw warning in "delimiter" category and
explain ambiguity of delimiter instead of emitting error and refusing
further interpretation of the escape sequence being parsed. Leave
behind "#if"ed code for restoration of former stricter behavior in a
future groff release (which would fix Savannah #66009).
(is_conditional_expression_true): Stop special-casing an exception for
`|` that permitted it to be used as a formatted output comparison
operator. Savannah #66481 complained only about groff's rejection of
`|` to delimit the argument to the `\w` (width measurement) escape
sequence, not in general, and was seen in some man pages. The usage
Paul Eggert reported remains accepted, albeit warned about, per
`do_width()` above.
* src/roff/groff/tests/check-delimiter-validity.sh: Update test
expectations. We now expect `|` to be invalid once again to delimit a
line-drawing escape sequence.
Fixes <https://savannah.gnu.org/bugs/?66686>. Thanks to Dave Kemper for
the report. Savannah #66526 is implicated.
The uses of `\w|whatever|` cited by Eggert appear to be a chunk of
boilerplate passed around by some man page authors for GNU man pages.
Eggert's "tz" package doesn't itself use `|` as a delimiter, but I did
verify their use in gawk, grep, and rcs.
gawk:
.if !\n(.g \{\
. if !\w|\*(lq| \{\
. ds lq ``
. if \w'\(lq' .ds lq "\(lq
. \}
. if !\w|\*(rq| \{\
. ds rq ''
. if \w'\(rq' .ds rq "\(rq
. \}
.\}
grep:
.if !\w|\*(lq| \{\
.\" groff an-old.tmac does not seem to be in use, so define lq and rq.
. ie \n(.g \{\
. ds lq \(lq\"
. ds rq \(rq\"
. \}
. el \{\
. ds lq ``
. ds rq ''
. \}
.\}
rcs:
.if !\n(.g \{\
. if !\w|\*(lq| \{\
. ds lq ``
. if \w'\(lq' .ds lq "\(lq
. \}
. if !\w|\*(rq| \{\
. ds rq ''
. if \w'\(rq' .ds rq "\(rq
. \}
.\}
One observes that only grep(1) doesn't feature-gate its use of `\w|foo|`
behind a test of the `.g` register (groff-compatible formatter) for
falsity. It is therefore the only one of these three that would have
provoked a warning. (What the foregoing do is reimplement the `lq` and
`rq` quotation strings, an extension from 4BSD (1980)--my guess is to
compensate for System V-based troffs missing them).
The rcs man pages otherwise use `\w` pretty extensively (which can be
its own portability worry), but in every other case with the unambiguous
`'` delimiter.
commit 1eed3cceaaa38e095e2b265cda846842853525e4
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date: Tue Jan 28 00:57:03 2025 -0600
[doc,man]: Report new delimiter warning scenario.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66481>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
