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
