Re: switch default MANPAGER from more(1) to less(1)

2020-07-19 Thread ropers
Ah, I see where you're coming from, Ingo. You've dropped the idea of testing for less(1) in non-portable mandoc because we know less(1) is in base.[1] That makes a lot of sense. Like you said, the idea of testing for less might be worth revisiting in mandoc-portable. Admittedly, testing for les

Re: switch default MANPAGER from more(1) to less(1)

2020-07-19 Thread Ingo Schwarze
Hi Jason & Theo, thanks for the feedback! Jason McIntyre wrote on Sun, Jul 19, 2020 at 05:02:02PM +0100: > i guess the argument in favour of more(1) would be that it is part of > posix, even if optional, where less(1) is not. so it makes sense to > choose a command most likely to work on most ma

Re: switch default MANPAGER from more(1) to less(1)

2020-07-19 Thread Theo de Raadt
> about -s: it's inclusion probably comes from a time when there was an > annoying bug in nroff that made our man pages randomly display a number > of blank lines in the middle of a page. -s mitigated that somewhat. that is also what I recall.

Re: switch default MANPAGER from more(1) to less(1)

2020-07-19 Thread Jason McIntyre
On Sun, Jul 19, 2020 at 05:36:34PM +0200, Ingo Schwarze wrote: > Hi, > > currently, if neither the MANPAGER nor the PAGER environment variable > is set, man(1) uses "more -s" as the manual page pager. I am quite > sure that the only reason i did this is that i thought this behaviour > was require

Re: switch default MANPAGER from more(1) to less(1)

2020-07-19 Thread Theo de Raadt
Good. The user-interface of less is slightly more refined, and definately preferred. Ingo Schwarze wrote: > Hi, > > currently, if neither the MANPAGER nor the PAGER environment variable > is set, man(1) uses "more -s" as the manual page pager. I am quite > sure that the only reason i did this

switch default MANPAGER from more(1) to less(1)

2020-07-19 Thread Ingo Schwarze
Hi, currently, if neither the MANPAGER nor the PAGER environment variable is set, man(1) uses "more -s" as the manual page pager. I am quite sure that the only reason i did this is that i thought this behaviour was required by POSIX. But it is not: https://pubs.opengroup.org/onlinepubs/969991

Re: xhci(4) isoc: fix bogus handling of chained TRBs

2020-07-19 Thread sc . dying
On 2020/07/19 11:25, Marcus Glocker wrote: > On Sun, 19 Jul 2020 02:25:30 + > sc.dy...@gmail.com wrote: > >> hi, >> >> It works on AMD Bolton xHCI (78141022), Intel PCH (1e318086), >> and ASM1042 (10421b21). >> I simply play with ffplay -f v4l2 /dev/video0 to test. > > If your cam supports MJ

Re: LC_MESSAGES in xargs(1)

2020-07-19 Thread Ingo Schwarze
Hi Martijn, Martijn van Duren wrote on Thu, Jul 16, 2020 at 11:13:31PM +0200: > I gave a quick look at replacing prompt with readpassphrase(3), but that > would be more trouble than it's worth. (adjusting pledge, semantics > change in where the "?..." would be printed). > > Minor nits inline, bu

snmpd(8) clean up snmpe_parsevarbinds

2020-07-19 Thread Martijn van Duren
I'm not quite sure yet where I want to move with snmpe_parsevarbinds, but the current implementation just gives me a headache every time I read it. There's still of plenty of issues in here, like not fully complient gathering of statistics, relying on synchronous handling of varbinds (required fo

Re: xhci(4) isoc: fix bogus handling of chained TRBs

2020-07-19 Thread Marcus Glocker
On Sun, 19 Jul 2020 02:25:30 + sc.dy...@gmail.com wrote: > hi, > > It works on AMD Bolton xHCI (78141022), Intel PCH (1e318086), > and ASM1042 (10421b21). > I simply play with ffplay -f v4l2 /dev/video0 to test. If your cam supports MJPEG it's good to add '-input_format mjpeg' with higher re