-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Comments
this is part of https://github.com/dotnet/corefx/issues/1626 |
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. |
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. |
@wfurt, is it still a problem with 2.1 (or master), ncurses 6.1 support is recently added? |
I did not try recently but I think so as everything is collapsed in single /usr/local/share/misc/terminfo.db file |
@wfurt Have you been able to look at this issue with recent versions of FreeBSD? |
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 |
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:
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 |
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 https://svnweb.freebsd.org/ports/head/devel/ncurses/Makefile?view=markup&pathrev=561386#l37 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
runtime/src/libraries/System.Console/src/System/TermInfo.cs Lines 177 to 182 in f473665
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 |
I thought ncurses is GPL but it seems like I was mistaken. I've also seen few projects with fixed set for most common terminals. Perhaps DUMB, ANSI, VT100/220 and XTERM would cover most cases. |
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 |
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 |
Summary of below: +1 to @jasonpugsley 's idea of a binaries package
That is certainly sounding like a better short term solution. terminfo.src as linked is either: licensed under ncurses MIT-style 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. |
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. |
@Thefrank Are you aware of https://svnweb.freebsd.org/ports?view=revision&revision=566840 ? Just thought that might be helpful! |
just built from ports. it installs to runtime/src/libraries/System.Console/src/System/TermInfo.cs Lines 177 to 182 in c07e1cf
|
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.
The text was updated successfully, but these errors were encountered: