Hi Dave, On Sat Nov 2, 2024 at 4:15 AM CET, Dave Kemper wrote: > Parsing strings that contain escapes is something that an open groff > bug report (http://savannah.gnu.org/bugs/?62264) seeks to make more > consistent. Does the mechanism proposed in that report sound like it > would solve the problem you're facing? (By default, the savannah bug > tracker displays comments from newest to oldest, but the thread will > be easier to follow if you click the "Reverse comment order" button in > the "Discussion" section.)
I am glad to hear it's a known issue/limitation that's being worked on. Adding a string iterator would fix this, although it would make my code significantly more complex as I would have to compare the strings character by character (my has-prefix macro can handle arbitrarily long prefixes, and I also have a has-suffix macro which would be even worse). A problem with this solution is that it's incomplete. It addresses a particular issue arrising from troff's usage of macro substitution, but doesn't solve the others. For instance, I would still run into issues if I tried to compare a literal ' against anything and delimited the comparands by the same character, which can happen with the proposed iterator mechanism: .ie '\\*[ch]'"' \" ... That's not meant as a criticism of the attempted fix, it's a general weak point in the design of the troff language (imho) which seems difficult to fix without redesigning the language.[1] ~ onf [1] Compare the results of the following snippets in POSIX sh and troff: $ sh $ str='"' $ [ "$str" = '"' ] && echo sh: double quote || echo sh: else sh: double quote $ groff -b -ww -z .ds str "'\" .ie '\*[str]'\'' .tm groff: single quote .el .tm groff: else groff: else Of course, the fun fact here is that Bourne shell's test command reportedly suffered from a similar issue in cases like: str='-e' [ "$str" = '-e' ] which would return false because the first argument was interpretted as the comparison operator -e rather than a string to be compared.
