Re: Escaping preference

[Ingo Schwarze <schwarze@usta.de>]

Hi Warren,

Warren Block wrote on Sun, Apr 17, 2016 at 10:20:23AM -0600:

> Just had a bug reported where "\n" used in code examples
> was not escaped and so renders improperly.
> 
>   printf("Bad input\n");
> 
> renders as
> 
>   printf("Bad input0);
> 
> on both FreeBSD 10 and 11 (groff and mandoc, respectively).

Indeed, that must be escaped.

The escape sequence '\n' interpolates a number register.
Specifically, '\n"' interpolates the number register with
the name '"'.  Since that number register will usually not
exist, it renders as '0'.  See roff(7), ESCAPE SEQUENCE
REFERENCE.  So the rendering is correct.

> https://www.freebsd.org/cgi/man.cgi?query=lsearch
> 
> Both of these escaped forms renders properly:
> 
>   printf("Bad input\\n");

NEVER use "\\" in manual pages.  It is *very* wrong.  Basically,
the "\\" escape sequence is only needed when implementing roff(7)
macro sets, that is, when writing macro definitions for macros that
take arguments.  Its purpose is to delay escape sequence expansion
- which sounds about as arcane as it indeed is.

But in the case at hand, you don't want to merely delay expansion
of "\n", you don't want "\n" at all.

>   printf("Bad input\en");

That's right.

> \e is recommended in Escaping Special Characters in mdoc(7) (really
> groff_mdoc(7)) on FreeBSD 10, not mentioned in mandoc's mdoc(7) on
> FreeBSD 11.

It's not specific to mdoc(7), but a basic roff(7) feature common
to any and all macro languages.  It is documented
 - in mandoc_char(7), subsection "Backslashes",
 - in roff(7), section LANGUAGE SYNTAX subsection "Special Characters"
 - in roff(7), section ESCAPE SEQUENCE REFERENCE subsection "\e".
 - in roff(7), section REQUEST REFERENCE subsection "de"
 - in roff(7), section MACRO SYNTAX,

> The double backslash appears preferable to me, more recognizable
> for people who might not be familiar with mdoc markup.  Is there
> any reason to prefer the \e version?

There is no guarantee that "\\" will work at all.  I may break
horribly in some contexts with some roff(7) implementations.  It
is among the roff(7) features hardest to understand and hardest to
predict what they may do.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv