groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] 02/05: nroff.1.man: Make editorial fixes.


From: Ingo Schwarze
Subject: Re: [groff] 02/05: nroff.1.man: Make editorial fixes.
Date: Sun, 30 Jun 2019 19:28:00 +0200
User-agent: Mutt/1.8.0 (2017-02-23)

Hi Brandon,

[pulling the point that is on-topic on this list up to the top]

G. Branden Robinson wrote on Sun, Jun 30, 2019 at 04:56:35AM +1000:
> Ingo Schwarze wrote:

>> I consider backspace encoding far superior to ISO 6429 SGR for
>> security reasons.

> I strongly disagree with this.  Implementations need not support every
> feature described by ISO 6429 and historically, I know of nothing that
> actually does.

That's not particularly relevant; what is releavnt is that many
implementations (including xterm(1)) implement several escapes that
are potentially dangerous.  In many implementations, most that are
potentially dangerous may be disabled by default, but who knows.

> The standards committee seems to have gotten carried away
> and added stuff

Yes; it's a standard committee after all...  :-/

>> Backspace encoding always works, and with no risk, whereas using ISO
>> 6429 SGR would require using the scary less(1) -R option.

> I'm not about to defend the design choices of the "less" program.

It isn't about one particular pager or terminal emulator implementation.
*Any* pager or terminal emulator that wants to support (some)
terminal escape sequences needs to make decisions which ones, which
ones are considered safe without options, and which options to
provide to enable some that may be less safe.  And then even if the
choices made in a given program of this kind are in principle reasonable,
this stuff is so complicated that there is a high risk of bugs making
usage unsafe.

So unless you really need SGR escapes (and are very careful about
which input you feed to your pager), it is best to just keep all
that scary stuff switched off.

Besides, i think less(1) is the de-facto standard pager by now,
so taking into account how it works is reasonable.

> But grotty doesn't output any ISO 6429 escape sequences that are
> inherently a security risk.  Do you disagree?

I don't know, i didn't check because it isn't really relevant.

What matters is whether enabling terminal escape sequences in your
pager may allow some sequences that might pose a risk, and
auditing *that* isn't quite trivial.

That's why i dislike (exaggerating a bit to make the point
more obvious) groff manual pages telling users

  "Set LESS=-r in your environment!"

without even mentioning any downsides.



The rest is just answering some of your questions for completeness:

> GMail is marking your mail as spam again.  This would be amusing if it
> weren't so irritating.  Your email address has not changed; why do I
> have keep to telling Google your mail is not spam?

Sorry, i can't help you to configure your very own spam filter
the way you want it, even less so without you providing any
information whatsoever.

>> Branden Robinson wrote:

>>>  .B \-h
>>> -(using tabs in the output) and
>>> +(use hard tabs in the output) and

>> While i see the point of explaining the mnemonic,
>> this is not the place.

I meant the nroff(1) manual page is not the place to explain the
mnemonics of the grotty(1) -h option because that is not even
a native nroff(1) option in the first place.

> I disagree with that rather stridently.  This is _exactly_ the
> place to explain why single-letter option names make any sense
> at all.

Well, the grotty(1) manual is the place, and you do now explain it
there.  :-)

> So I violently oppose not explaining option mnemonics in man pages for
> similar reasons

By all means, do explain option mnemonics - at the place of the
manual page where the option in question is documented, but not
not in a *different* manual page merely mentioning it in passing.

While the discussion of conciseness+simplicity versus verboseness+option
proliferation is interesting, i see little need to rehash it here.  ;)

Yours,
  Ingo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]