Date: Mon, 04 May 2020 06:35:03 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: sysutils/screen-ncurses port Message-ID: <202005041335.044DZ3m1054565@slippy.cwsent.com> In-Reply-To: <20200504072624.wlyd73pehq25tcp2@ivaldir.net> References: <202004291841.03TIfkZh081308@slippy.cwsent.com> <20200430075337.3wdzglshhorcd2qn@ivaldir.net> <202004301256.03UCusls050859@slippy.cwsent.com> <20200430130449.cwsf3x42o6w67gor@ivaldir.net> <202005032010.043KAwm9005791@slippy.cwsent.com> <20200504072624.wlyd73pehq25tcp2@ivaldir.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20200504072624.wlyd73pehq25tcp2@ivaldir.net>, Baptiste
Daroussin wr
ites:
>
>
> --ma2vde2ykv3k7k6b
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > In message <20200430130449.cwsf3x42o6w67gor@ivaldir.net>, Baptiste=20
> > Daroussin wr
> > ites:
> > >=20
> > >
> > > --mvhxgm4zl62unzlf
> > > Content-Type: text/plain; charset=3Dus-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > In message <20200430075337.3wdzglshhorcd2qn@ivaldir.net>, Baptiste=3D=
> 20
> > > > Daroussin wr
> > > > ites:
> > > > >=3D20
> > > > >
> > > > > --vwrr5drfobpkyvop
> > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > Content-Disposition: inline
> > > > > Content-Transfer-Encoding: quoted-printable
> > > > >
> > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> t th=3D
> > > at=3D3D
> > > > > =3D3D20
> > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> for =3D
> > > this=3D3D
> > > > > =3D3D20
> > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> t ex=3D
> > > ist =3D3D
> > > > > in=3D3D20
> > > > > > termcap(5). People who want that extra functionality would be adv=
> ised=3D
> > > to=3D3D
> > > > > =3D3D20
> > > > > > install the alternative pkg or build the sysutils/screen port wit=
> h th=3D
> > > e=3D3D20
> > > > > > appropriate option.
> > > > > >=3D3D20
> > > > > > Or, simply change the default from whatever ncurses is available =
> to a=3D
> > > lway=3D3D
> > > > > s=3D3D20
> > > > > > install devel/ncurses. People could always select one of the othe=
> r op=3D
> > > tion=3D3D
> > > > > s.=3D3D20
> > > > > > Personally, I'm not enamoured with this approach.
> > > > >
> > > > > I think it is a terrible idea, and we should fix the initial proble=
> m in=3D
> > > stea=3D3D
> > > > > d of
> > > > > workarounding it.
> > > > >
> > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> ey a=3D
> > > re
> > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > >=3D20
> > > > I came to this conclusion last night after sending this email thread =
> oud=3D
> > > =3D20
> > > > and will test it some time today.
> > > >=3D20
> > > > >
> > > > > 2/ we should allow our base ncurses to get informations from newer =
> term=3D
> > > cap(=3D3D
> > > > > 5) if
> > > > > needed.
> > > > > So far the default TERMCAP is
> > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> =2Edb}
> > > > >
> > > > > First the user can be advise to point configure the $home/.termcap =
> this=3D
> > > is =3D3D
> > > > > for
> > > > > quick now.
> > >
> > > that is in your scope via a pkg-message :D
> > >
> > > > >
> > > > > Second for later futur proof mechanism we could modify our termcap =
> read=3D
> > > er (=3D3D
> > > > > we
> > > > > use our own, not the one in provided by ncurses). to be able to fet=
> ch t=3D
> > > ermc=3D3D
> > > > > ap
> > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > > >
> > > > > This way ports with random termcap info to add would be able to do =
> it w=3D
> > > itho=3D3D
> > > > > ut
> > > > > the requirement to wait for a commit in base and a MFC.
> > > >=3D20
> > > > This is probably outside of my scope at the moment but, yes, agreed.
> > > >=3D20
> > > I will then.
> > > I added that to my TODO
> >=20
> > There's already a utility in devel/ncurses called infotocap (and its=20
> > corresponding captoinfo) that already does this. Both are links to tic. O=
> ur=20
> > ncurses import includes tic. Looks like all that's needed is add it to=20
> > buildworld.
> >=20
> > I can look at it later tonight. Seems like a quick win.
> >=20
> That is not the point, tic won't work here except if create your own versio=
> n or
> use infotocap. Tic is for terminfo databases while we are still using the=
> =20
> termcap for historical reason
I'm not suggesting replacing all of termcap. Just adding some converted
screen.* entries.
>
> Having both ncurses from ports and ncurses from base installed at the same =
> time
> can open a special can of worm so imho that is not really something we want=
> to
> look forward.
Some ports require ncurses from ports. Same can of worms as installing a
kerberos or openssl port.
--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org
NTP: <cy@nwtime.org> Web: https://nwtime.org
The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202005041335.044DZ3m1054565>