Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FreeBSD: System.Console is not working right #23653

Closed
wfurt opened this issue Sep 26, 2017 · 16 comments · Fixed by #55152
Closed

FreeBSD: System.Console is not working right #23653

wfurt opened this issue Sep 26, 2017 · 16 comments · Fixed by #55152
Labels
area-System.Console bug help wanted [up-for-grabs] Good issue for external contributors os-freebsd FreeBSD OS
Milestone

Comments

@wfurt
Copy link
Member

wfurt commented Sep 26, 2017

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
Copy link
Member Author

wfurt commented Sep 27, 2017

@RussellHaley
Copy link

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
Copy link
Member Author

wfurt commented Sep 28, 2017

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
Copy link

ghost commented Apr 12, 2018

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

@wfurt
Copy link
Member Author

wfurt commented Apr 12, 2018

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

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@carlossanlop
Copy link
Member

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

@carlossanlop carlossanlop removed the untriaged New issue has not been triaged by the area owner label Mar 4, 2020
@wfurt
Copy link
Member Author

wfurt commented Mar 4, 2020

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
Copy link
Member Author

wfurt commented Jan 14, 2021

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
Copy link
Contributor

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

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
Copy link
Member Author

wfurt commented Jan 14, 2021

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member Author

wfurt commented Jan 15, 2021

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
Copy link

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

@Thefrank
Copy link
Contributor

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

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

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Jul 5, 2021
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jul 5, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Aug 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Console bug help wanted [up-for-grabs] Good issue for external contributors os-freebsd FreeBSD OS
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants