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

terminfo parser is ineffective on FreeBSD #55274

Closed
ararslan opened this issue Jul 27, 2024 · 4 comments · Fixed by #55411
Closed

terminfo parser is ineffective on FreeBSD #55274

ararslan opened this issue Jul 27, 2024 · 4 comments · Fixed by #55411
Labels
regression Regression in behavior compared to a previous version regression 1.11 Regression in the 1.11 release system:freebsd Affects only FreeBSD

Comments

@ararslan
Copy link
Member

The intersection of #53682 with #50797 causes a test failure on FreeBSD: it has to compile Base.info_color(), so it has 1 rather than 0 expected precompiles. This is because FreeBSD doesn't use terminfo, it uses termcap1, so our terminfo parser always fails to find an entry on FreeBSD and we end up with a blank TermInfo. I had wondered why my Julia REPL colors disappeared, evidently this is why.

A couple of options I can think of:

The latter would be the more consistent with how we deal with other dependencies. The former would likely be rather involved.

cc @tecosaur

Footnotes

  1. At least as of 2020, FreeBSD was looking to switch to terminfo, though I've not seen movement on that since then.

@ararslan ararslan added regression Regression in behavior compared to a previous version system:freebsd Affects only FreeBSD regression 1.11 Regression in the 1.11 release labels Jul 27, 2024
@tecosaur
Copy link
Contributor

Hmm, I'm not specifically familiar with the freebsd builds. From a glance though, vendoring BSD's terminfo-db just with the BSD build seems like a promising option to me (presuming that can work).

@ararslan
Copy link
Member Author

We'd want to vendor and use it everywhere to ensure consistency between platforms like we do with other dependencies. It's worth noting that even though I linked to the FreeBSD port for terminfo-db, it's not actually specific to FreeBSD in any way, it's just the directory-based terminfo database that's provided by the ncurses developers.

I've attempted making a JLL for this purpose in JuliaPackaging/Yggdrasil#9165. The idea is that we'd include the JLL in stdlib/ alongside the other JLLs and provide the build recipe in deps/ to facilitate USE_BINARYBUILDER=0 builds. The terminfo parser in Base can then use the artifact's location by default, perhaps prepended to TERMINFO_DIRS. That way, users can still opt into using the local definitions on their system by setting the TERMINFO variable or populating ~/.terminfo, and we remain compliant with terminfo(5).

@tecosaur
Copy link
Contributor

tecosaur commented Jul 31, 2024

Right, I'm with you: if we're going to go to the effort of vendoring it for FreeBSD, we might as well use it everywhere. It leaves us less exposed to what happens to be installed (or not) on the host system and it's only ~7 MB (and we could always strip out rare terminals and introduce a default fallback if we ever wanted to slim that down further).

Re-reading this bit of terminfo(5):

Fetching Compiled Descriptions
   Fetching Compiled Descriptions
       The ncurses library searches for terminal descriptions in several
       places.  It uses only the first description found.  The library
       has a compiled-in list of places to search which can be
       overridden by environment variables.  Before starting to search,
       ncurses eliminates duplicates in its search list.

       •   If the environment variable TERMINFO is set, it is
           interpreted as the pathname of a directory containing the
           compiled description you are working on.  Only that directory
           is searched.

       •   If TERMINFO is not set, ncurses will instead look in the
           directory $HOME/.terminfo for a compiled description.

       •   Next, if the environment variable TERMINFO_DIRS is set,
           ncurses will interpret the contents of that variable as a
           list of colon-separated directories (or database files) to be
           searched.

           An empty directory name (i.e., if the variable begins or ends
           with a colon, or contains adjacent colons) is interpreted as
           the system location @TERMINFO@.

       •   Finally, ncurses searches these compiled-in locations:

           •   a list of directories (@TERMINFO_DIRS@), and

           •   the system terminfo directory, @TERMINFO@ (the compiled-
               in default).

I'd be inclined to add Julia's vendored terminfo dir to @TERMINFO_DIRS@ / terminfo_dirs, which I think is what you're proposing? (having the named "TERMINFO_DIRS" and also the environment variable TERMINFO_DIRS makes things a bit ambiguous).

@ararslan
Copy link
Member Author

What I was proposing was actually more like prepending it to the environment variable TERMINFO_DIRS but what you said makes more sense. 😅

vtjnash pushed a commit that referenced this issue Aug 8, 2024
This adds the `terminfo` database to `deps/`, providing a better user
experience on systems that don't have `terminfo` on the system by
default. The database is built using BinaryBuilder but is not actually
platform-specific (it's built for `AnyPlatform`) and as such, this
fetches the artifact directly rather than adding a new JLL to stdlib,
and it requires no compilation.

A build flag, `WITH_TERMINFO`, is added here and assumed true by
default, allowing users to set `WITH_TERMINFO=0` in Make.user to avoid
bundling `terminfo` should they want to do so.

The lookup policy for `terminfo` entries is still compliant with what's
described in `terminfo(5)`; the bundled directory is taken to be the
first "compiled in" location, i.e. prepended to `@TERMINFO_DIRS@`. This
allows any user settings that exist locally, such as custom entries or
locations, to take precedence.

Fixes #55274

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>
lazarusA pushed a commit to lazarusA/julia that referenced this issue Aug 17, 2024
…#55411)

This adds the `terminfo` database to `deps/`, providing a better user
experience on systems that don't have `terminfo` on the system by
default. The database is built using BinaryBuilder but is not actually
platform-specific (it's built for `AnyPlatform`) and as such, this
fetches the artifact directly rather than adding a new JLL to stdlib,
and it requires no compilation.

A build flag, `WITH_TERMINFO`, is added here and assumed true by
default, allowing users to set `WITH_TERMINFO=0` in Make.user to avoid
bundling `terminfo` should they want to do so.

The lookup policy for `terminfo` entries is still compliant with what's
described in `terminfo(5)`; the bundled directory is taken to be the
first "compiled in" location, i.e. prepended to `@TERMINFO_DIRS@`. This
allows any user settings that exist locally, such as custom entries or
locations, to take precedence.

Fixes JuliaLang#55274

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>
KristofferC pushed a commit that referenced this issue Aug 19, 2024
This adds the `terminfo` database to `deps/`, providing a better user
experience on systems that don't have `terminfo` on the system by
default. The database is built using BinaryBuilder but is not actually
platform-specific (it's built for `AnyPlatform`) and as such, this
fetches the artifact directly rather than adding a new JLL to stdlib,
and it requires no compilation.

A build flag, `WITH_TERMINFO`, is added here and assumed true by
default, allowing users to set `WITH_TERMINFO=0` in Make.user to avoid
bundling `terminfo` should they want to do so.

The lookup policy for `terminfo` entries is still compliant with what's
described in `terminfo(5)`; the bundled directory is taken to be the
first "compiled in" location, i.e. prepended to `@TERMINFO_DIRS@`. This
allows any user settings that exist locally, such as custom entries or
locations, to take precedence.

Fixes #55274

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>
(cherry picked from commit e7e8768)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression Regression in behavior compared to a previous version regression 1.11 Regression in the 1.11 release system:freebsd Affects only FreeBSD
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants