Too many levels of symbolic links at share/terminfo/N/NCR260VT300WPP

[oxidase]

In 5246d4e --enable-symlinks creates a circular symlink in case-insensitive file systems like APFS.

share/terminfo/N/NCR260VT300WPP --> ../n/ncr260vt300wpp

which leads to problems with globs in bazel.

The fix must be included into upstream and as an interim solution --enable-symlinks can be commented out.

[oxidase]

It looks like the issue was addressed on 2000/11/11

20001111
	+ modify _nc_write_entry() to allow for the possibility that linking
	  aliases on a filesystem that ignores case would not succeed because
	  the source and destination differ only by case, e.g., NCR260VT300WPP0
	  on cygwin (report by Neil Zanella).

For terminfo built on a case-sensitive FS glob fails on a case-insensitive FS with enabled symlinks.

[indygreg]

Ugh. This bug just shouldn't exist in the terminfo database :/

FWIW I enabled symlinks because by default hardlinks are created. And hardlinks and tar archives don't exactly play well together.

It looks like by default the terminfo database has directories like A, B, C, a, b, c, etc. Obviously not compatible with case insensitive filesystems.

terminfo does have a --disable-mixed-case configure flag. This appears to swap out the top-level directory with the ASCII hex encoding equivalent. e.g. 41, 42, 43, 61, 62, 63.

It appears the macOS terminfo database uses this --disable-mixed-case mode (see /usr/share/terminfo on a macOS machine).

We can add --disable-mixed-case to produce a terminfo database that doesn't cause problems for case insensitive filesystems.

But, it appears that --disable-mixed-case changes the semantics for ncurses to resolve filesystem paths at run-time as well. If you build ncurses with --disable-mixed-case, it looks for entries using the hex encoding instead of the ascii letter. So if we pick up the /usr/share/terminfo database from the Linux host, it will fail to find files because it is looking in the wrong location.

I added a copy of the terminfo database to the tar archives for convenience. I doubt most consumers will actually use the terminfo database from the archives directly because this requires setting up an environment variable to point ncurses at a non-default directory containing the database.

Since the terminfo database isn't usable out of the box, I'm tempted to either delete it. Or if people think it could be useful, we could package it as a nested tar archive so downstream consumers could extract it. This will solve the problem of a case insensitive tar extractor not being able to extract the archive due to case conflicting symlinks.