Re: Preferred TERM for pkg_add

2023-01-29 Thread Theo de Raadt
Marc Espie wrote: > Actual patches to pkg_add (if need be) welcome > > The switch to not using full term length was actually done at Theo's > request. > > I don't remember the details, but Theo's rationale was quite > reasonable and made lots of sense. > > (specifically, using the full line le

Re: Preferred TERM for pkg_add

2023-01-29 Thread Marc Espie
Actual patches to pkg_add (if need be) welcome The switch to not using full term length was actually done at Theo's request. I don't remember the details, but Theo's rationale was quite reasonable and made lots of sense. (specifically, using the full line length would be cool, but there were lot

Re: Preferred TERM for pkg_add

2023-01-18 Thread Stuart Henderson
Is there any benefit to pkg_add's TERM handling now that it no longers uses the full terminal width? To my eye the visual output looks the same with TERM=dumb (though presumably it will avoid the intermittent problem where somewhere between pkg_add, termcap and urxvt, pkg_add -u output jumps to th

Re: Preferred TERM for pkg_add

2023-01-17 Thread Patrik Lundin
On Mon, Jan 09, 2023 at 01:52:03PM +, Nicholas Marriott wrote: > > From a quick look it will happily fall back to carriage return and space > if the capabilities it would prefer (el and hpa/RI) are not present, so > probably anything would do. > > Or you could check if the terminfo entry exis

Re: Preferred TERM for pkg_add

2023-01-09 Thread Nicholas Marriott
>From a quick look it will happily fall back to carriage return and space if the capabilities it would prefer (el and hpa/RI) are not present, so probably anything would do. Or you could check if the terminfo entry existed with something like "tput el >/dev/null 2>&1" before running pkg_add. O