FreeBSD: System.Console is not working right

[wfurt]

This is because terminfo database is missing in default installation.
I tried to add ncurses package from ports.
That only creates /usr/local/share/misc/terminfo.db
And the terminal information is kept in hashed form.

We shall investigate.

[wfurt]

this is part of https://github.com/dotnet/corefx/issues/1626

[RussellHaley]

https://forums.freebsd.org/threads/8101/

Does this info help? does termcap(5) provide what you need? If not, there is a suggestion for getting the devel/ncurses package.

[wfurt]

yes I saw that. That means manual rebuild of ports. We can possibly give up on fancy parts - like colors - for now. I think termcap is equivalent information but somebody would need to write code to deal with it.

For now, I just copy terminfo from Linux to get by.

[ghost]

@wfurt, is it still a problem with 2.1 (or master), ncurses 6.1 support is recently added?

[wfurt]

I did not try recently but I think so as everything is collapsed in single /usr/local/share/misc/terminfo.db file

[carlossanlop]

@wfurt Have you been able to look at this issue with recent versions of FreeBSD?

[wfurt]

no, I have not. It has been like this for ages. They generally use termcap format to describe terminal capabilities. We can either 1) figure out how to read that, 2) figure out how to get uncompressed terminfo or 3) give up on enhanced terminal capabilities for now and that it as dumb terminal.

[wfurt]

Forking back from main FreeBSD thread @emaste @jasonpugsley @Thefrank

What we need are sequences for particular terminal. On Linux this is currently done in management code where this reads unpacked files for each individual terminal.

I think we have three basic options:

• read termcap instead and get equivalent information.
• use terminfo from nurse package or base OS if available
• somehow create to what .NET expects

While I did not proceed fast enough on first option I jumped back to last and copy the database. I know there was suggestion to wrap that as separate package. While that gives perhaps fastest workable solution I don't like is it creates duplication and ongoing maintenance.

I would probably be in favor of the middle road and process binary terminfo either via invoke of via PAL. If libdbm (or what ever) is always available (or we can make it dependency) we can link with it when we build libSystemNative.so
Somebody would need to figure out how to extract the relevant bits. I assume that the actual information would be 1:1 with the "uncompress" version.

[Thefrank]

much of this has already been covered above but for those that want their information embedded...

method 2 would be the easiest but unfortunately FreeBSD in both pkg and ports builds ncurses with --with-hashed-db which causes things like tic to be unable to write entries into a tree format. In ports this is fixable by just removing that line but that brings up other issues like mixings ports and pkg installs or the requirement to edit a makefile.

https://svnweb.freebsd.org/ports/head/devel/ncurses/Makefile?view=markup&pathrev=561386#l37
https://github.com/ThomasDickey/ncurses-snapshots/blob/e6f3d11be6d61767321477c3fa16100133ee2796/INSTALL#L965

also, the terminfo file/tree from pkg install ends up in a place where it would not be found currently, though that is easily fixable. the second entry is just a symlink to /usr/share/misc/termcap

# infocmp -D
/usr/local/share/misc/terminfo
/etc/termcap

runtime/src/libraries/System.Console/src/System/TermInfo.cs

Lines 177 to 182 in f473665

	private static readonly string[] _terminfoLocations = new string[] {
	"/etc/terminfo",
	"/lib/terminfo",
	"/usr/share/terminfo",
	"/usr/share/misc/terminfo"
	};

method 1 has its own issues as termcap and terminfo arent 1:1 compatible afaik but ncurses does provide tools to convert terminfo and termcap entries into each other infocmp -I and infocmp -Cr both of which are just tic with extra steps
The hashed db and tree versions should be 1:1 but im not 100% certain of that.

[wfurt]

I thought ncurses is GPL but it seems like I was mistaken.
Perhaps we can use nurses if available via dlopen in PAL? As somebody already mentioned not every app needs fancy terminal.

I've also seen few projects with fixed set for most common terminals. Perhaps DUMB, ANSI, VT100/220 and XTERM would cover most cases.

[Thefrank]

ncurses is... complicated wrt licensing. the closest similar match (but not exact) would be MIT-X11.

It is however, not licensed under that either.

the long version: https://invisible-island.net/ncurses/ncurses.faq.html#who_owns_it
the very long version: https://invisible-island.net/ncurses/ncurses-license.html

[jasonpugsley]

Perhaps DUMB, ANSI, VT100/220 and XTERM would cover most cases

Yes, I would expect xterm compatibility would cover the vast majority of potential terminals that people would be using in 2021.

Another option would be to use the terminfo.src file directly terminfo.src.gz it doesn't appear to currently have a license. I did try to process it and create a resx/resources file (System.Resources) only to find that binary resources are not supported (available only on Windows?). I tried outputting as a JSON file and that ended up at 6MB when the original terminfo.src is only 1MB :) I'm not sure how else we could include the data in the Runtime if that's even desirable.

I do think providing a prebuilt binary package of just the database tree would be a good interim solution. It should install into /usr/share/misc/terminfo/*/* which is what you see in the man page for terminfo on FreeBSD. A package name of terminfo-data shouldn't clash with anything else.

[Thefrank]

Summary of below: +1 to @jasonpugsley 's idea of a binaries package

I do think providing a prebuilt binary package of just the database tree would be a good interim solution.

That is certainly sounding like a better short term solution.
Installation to /usr/share/misc/terminfo/*/* would fall under the search tree that TermInfo.cs uses and prevent the need to make changes to that code. I am unsure why devel/ncurses installs to /usr/local/share/misc/terminfo but I am likely forgetting something about canonical locations.

terminfo.src as linked is either:

licensed under ncurses MIT-style
or
contains no explicit copyright

depending on how you read it. The later makes it very easy to include/use and the former should(?) be compatible with the MIT licensing of dotnet/runtime even though they are not word-word exact. [I am not a lawyer, this is simply a best guess based on reading]

now as for terminal usage in 2021. xterm is the more popular. I installed a number of free and commercial (where limited trials were available) terminal/ssh/telnet/rlogin/serial clients (FOR WINDOWS) to see what they offered as terminal options. All of them had: ANSI, VT100, Xterm, Dumb. Most of them had some other variations of VT10X, VT2XX, WYSE, Linux. The default in all but 2 cases was xterm. vt100 was the other default.

[wfurt]

we can make code changes. @emaste would probably know if the BSD community would even take package with terminfo database. I'm personally OK with that as short term fix.

[dasschellack]

@Thefrank Are you aware of https://svnweb.freebsd.org/ports?view=revision&revision=566840 ? Just thought that might be helpful!

[Thefrank]

just built from ports. it installs to /usr/local/share/misc/terminfo/ and uses directory tree!
guess now that is uses directory tree that path can get added to

runtime/src/libraries/System.Console/src/System/TermInfo.cs

Lines 177 to 182 in c07e1cf

	private static readonly string[] _terminfoLocations = new string[] {
	"/etc/terminfo",
	"/lib/terminfo",
	"/usr/share/terminfo",
	"/usr/share/misc/terminfo"
	};