Follow-up Comment #3, bug #66481 (group groff): I can fix this but GNU _troff_ is still going to be stricter than AT&T _troff_, albeit not with respect to the `\w` escape sequence, which accepts what we might call a "general" argument rather than a numeric expression argument.
Consider use of the `\l` escape sequence, which accepts a numeric expression argument, and optionally, a character to draw the line with. If said character would be valid in a numeric expression, it must be preceded by a dummy character escape sequence. However, AT&T _troff_ still accepts (apparently) _any_ delimiter that would be valid for more general input. $ printf '\\l"5n\\&*"\n' | DWBHOME=~/dwb ~/dwb/bin/nroff | cat -s ***** $ printf '\\l|5n\\&*|\n' | DWBHOME=~/dwb ~/dwb/bin/nroff | cat -s ***** $ printf '\\l95n\\&*9\n' | DWBHOME=~/dwb ~/dwb/bin/nroff | cat -s ***** $ printf '\\l95n\\&*9\n' | nroff | cat -s troff:<standard input>:1: error: character '9' is not allowed as a delimiter 5n*9 Moreover, in anticipation of gripes from certain quarters, I observe that this behavior is not an instance of me being a jerkfaced fascist with respect to input cleanliness. Jackboot prints have long gouged the earth of our input parser's hiking trail. $ printf '\\l95n\\&*9\n' | ~/groff-1.22.3/bin/nroff | cat -s <standard input>:1: cannot use character `9' as a starting delimiter 5n*9 If I had to wager, I'd bet that the foregoing input has been rejected by GNU _troff_ since day one. If this sort of tomfoolery was once "commonly used" as Paul said of `\w|`, 35 years of _groff_ influence have, I suspect, boiled it away. `printf '\\l95n\\&*9\n'` strikes me as too perverse a use case to support. Even if people lean on me to support it, I feel confident that I'd stuff it behind AT&T compatibility mode. There are few, if any, reasons to use exotic delimiters in GNU _troff_.[1] So I will do as Paul suggests, but I will not go further at this time, and maybe not ever. 5.6.5 Delimiters ---------------- [snip] Delimiter syntax is complex and flexible primarily for historical reasons; the foregoing restrictions need be kept in mind mainly when using 'groff' in AT&T compatibility mode. GNU 'troff' keeps track of the nesting depth of escape sequence interpolations, so the only characters you need to avoid using as delimiters are those that appear in the arguments you input, not any that result from interpolation. Typically, ''' works fine. *Note Implementation Differences::. (The foregoing language also appears in section "Delimiters" of _groff_(7).) [1] And if you want exotic, do what GNU _tbl_ does. Select a bespoke special character to serve as your delimiter. (You don't even have to _define_ this special character with the `char` request--since it is never used to format anything, but only to delimit input, it never provokes a diagnostic. Neat trick!) https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/tbl/table.cpp?h=1.23.0#n29 _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66481> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
