I have a couple questions about groff strings. 1. In its section about the \* escape to interpolate a string, the current manual text states, "The delimited form need not use the neutral apostrophe; see *note Delimiters::." But the example above shows [ and ] as delimiters, and in fact single quotes (neutral apostrophes) do not seem to work as \* delimiters:
$ cat test1 .ds mystring hello \*[mystring] \*'mystring' $ groff -Tascii test1 | cat -s hello mystring' The output indicates that groff is parsing "\*'mystring'" as a(n undefined) string called "\*'" followed by the text "mystring'". Is this reference to neutral apostrophes an error, or is there some aspect of this I'm not understanding? 2. The manual also states, "In contrast to macro invocations, however, a closing bracket as a string argument must be enclosed in double quotes." But in practice this seems to be true of not just a closing bracket on its own, but anything containing a closing bracket. Observe the difference: $ cat test2 .ds mystring2 hello \\$1 .nf \*[mystring2 world] \*[mystring2 "]"] \*[mystring2 "\[aq]"] $ groff -Tascii test2 | cat -s hello world hello ] hello ' $ cat test3 .ds mystring2 hello \\$1 .nf \*[mystring2 world] \*[mystring2 "]"] \*[mystring2 "\[aq]"] \*[mystring2 \[aq]] $ diff test2 test3 5a6 > \*[mystring2 \[aq]] $ groff -Tascii test3 | cat -s troff:test3:6: error: newline character not allowed in escape sequence parameter hello world hello ] hello ' hello Is this the expected behavior? The error message in particular gives little indication of what the actual problem is. (This behavior has been the same since at least groff 1.19.2, though after 1.22.4 the error text was tweaked, now saying "escape sequence parameter" where it used to say "escape name.") More significantly, it's unclear why "\*[mystring2 \[aq]]" shouldn't be parseable. Clearly a "]" on its own needs the quotes to disambiguate it from the closing bracket of the \* escape. But the opening bracket of the inner "\[aq]" ought to be able to tell groff that the next closing one is associated with that escape rather than with the outer one. So, is the fact that this doesn't parse as expected a bug? Or is this not supposed to work, but the error text is suboptimal for explaining the problem? Thanks for any insight.
