Talk:Terminfo

infocmp vs untic

pcurses had compile/dump programs, which in ncurses evolved to tic/infocmp

Other than ncurses, infocmp was developed at AT&T

• O'Reilly book on terminfo cites Tony Hansen
• comment in source-code for infocmp.c, Tony Hansen, February 23, 1984

untic appears to have been developed independently, and later incorporated by HP and others:

• Dave Regan (December 1, 1986). "untic". comp.sources.unix archive. Retrieved 2007-11-16.
• Dave Regan (June 6, 1991). comp.sources.unix archive http://www.isc.org/sources/utils/terminal/untic2.txt. Retrieved 2007-11-16. {{cite web}}: Missing or empty |title= (help)
• "UTECH.001". Uniplex. 1991/07/25. Retrieved 2007-11-16. {{cite web}}: Check date values in: |date= (help)
• "untic(1M)". HP. Retrieved 2007-11-16.
• Chris Ritson (June, 17 1993). "SUMMARY: terminfo/termcap translation". Retrieved 2007-11-16. {{cite web}}: Check date values in: |date= (help)

Ross's mytinfo used tconv, as noted here (originally 1994):

• The ADOM Fluff FAQ

Tedickey (talk) 18:50, 18 November 2007 (UTC)

terminfo tutorials

• A termcap/terminfo Description for xterm

Tedickey (talk) 23:13, 16 November 2007 (UTC)

"... A terminfo entry may use negative numbers to represent cancelled or absent values."

And even more importantly, attributes that may have a valid negative value!. Of which arguably the most common might be "xmc" ("magic cookie"), which on some older terminals can have a valid value of -1. Old_Wombat (talk) 05:31, 8 January 2012 (UTC)

That's an internal value. A terminal description can only specify positive numbers. TEDickey (talk) 11:27, 8 January 2012 (UTC)

We must be talking about different Unixes. When I worked for the corporation and we first started with Unix, we had Adds Viewpoint terminals. The magic cookie value for this terminal was -1. So the terminfo value was xmc#-1.

Looks like that is no longer true, though. I note the latest man page for terminfo specifically says a positive number. Old_Wombat (talk) 09:26, 10 January 2012 (UTC)

A likely place to look would be in older (HPUX 9 or 10) manpages, since HPUX had/has support for that flavor of xmc. The newer stuff is based on X/Open, which states the limits are 0 to 32767. TEDickey (talk) 11:39, 10 January 2012 (UTC)

Inspired by all this nostalgia, I took a look at some of my old emails. Looks like the -1 value was a hack that was put in specifically for some problems relating to RM-COBOL. Gosh, that was a long time ago. The CPU in question was the old 16-bit Motorola 68000. Clearly none of this stuff is relevant now. Old_Wombat (talk) 08:57, 11 January 2012 (UTC)

The CPU is irrelevant; the terminal (or emulator) might be of interest TEDickey (talk) 11:59, 11 January 2012 (UTC)

Portability of compiled terminfo files

Mr Tedickey, you should know that you removed correct information. Why do you do that? --Schily (talk) 16:55, 9 January 2012 (UTC)

Oh. Are you going to provide a WP:RS, or is this the usual personal attack from you? TEDickey (talk) 17:16, 9 January 2012 (UTC)

I see your delete operation as one of your typical personal attacks. The content you removed is verifed by other accepted statements in the article. So you need to prove that the information you removed is wrong even though it just makes other existing and accepted information from the article better understandable. --Schily (talk) 18:05, 9 January 2012 (UTC)

That's simple enough (though if you don't really understand the problem you're reporting, demonstrating a solution may be difficult) TEDickey (talk) 18:15, 9 January 2012 (UTC)

I've reviewed the edit history and agree with Tedickey. The content Schily would like to add may be true and possibly suggested by other content or sources already in the article. But the statement itself is impermissible WP:OR unless a source can be provided. Msnicki (talk) 18:39, 9 January 2012 (UTC)

If you believe there is a need for additional sources, then you seem to believe that the current state of the article is not correct and should either get more quotes or get revised. The statement I added is already proved by the sentence: "Because the compiled terminfo entries do not contain metadata identifying the indices within the tables to which each capability is assigned, they are not necessarily compatible between implementations.", but my statement made the related consequences more obvious to quick readers.

In fact, I found a binary terminfo database on HP-UX that was not compatible with the binary terminfo from Solaris. It sems that Tedickey has a personal interest in hiding related information. --Schily (talk) 17:33, 30 January 2012 (UTC)

There may be a particular way to rephrase it which makes it WP:True, however the issue raised in the comment is something that can be addressed using the login scripts of the user. (Noting that Wikipedia is not a reliable source, the example should be presented elsewhere, in case the demonstration is intended to be generally useful) TEDickey (talk) 19:03, 9 January 2012 (UTC)

"Improvements over termcap".

An important improvement that is not mentioned is that a termcap definition was conceptually a single line. So when you wrote it out over multiple lines, you had to have backslashes in all but the last line, and the total number of characters (including all whitespaces) you were limited to whatever "linelength" was for your Unix de jour. So if, for example, your terminal had 16 function and other keys, and your linelength was say 1024 (a common value in pre-terminfo days), you may have had difficulty putting all of those attributes in. With terminfo, your source file size could be much greater and this problem did not occur.

Another important difference between termcap and terminfo was that in the former you could arbitrarily create attribute names and give them values; with terminfo, you could only include what tic (or whatever corresponding utility you had) supported. Old_Wombat (talk) 09:19, 11 January 2012 (UTC)

Terminfo tried to address performance problems that were specific to the UNIX v7 filesystem that was still used by AT&T in the early 1980s. Compared to the state of the art with termcap on BSD UNIX in 1982, this was a slow down. Note that around 1980 people did already learn to store parsed termcap entries in the environment which reduced the number of file accesses to one per login. Also reading one large file was already fast in the BSD-4.2 filesystem (UFS/FFS) and reading a small file from a directory tree with many entries at that time was slower than opening/reading one single file. Compiled terminfo entries are still limited to 4095 bytes and aprox. 1000 bytes from that are used by the structure of the file. Modern termcap implementations on the other side support unlimited entry lenghts and an unlimited number of tc= entries. As a result, I cannot see real improvements with terminfo - it seems that the advantages (such as longer entries by default) are in balance to the disadvantages (such as binary compatibility). --Schily (talk) 18:08, 30 January 2012 (UTC)

Responding to the first, that's brought out and discussed in detail in TCTEST - A Termcap Test Utility, noting that the 1023-byte limit is computed differently for BSD4.3 and later (since excess whitespace is discarded on loading into the terminal database). Compiled terminfo entries are limited to 4096 bytes. In both cases, that is a conventional limit which could be altered (at the cost of portability). For the second, that's true enough, but ncurses has (since 1999) supported user-defined capabilities. Other implementations do not do this; however there is nothing in the terminfo syntax which prevents this (ncurses being an example). At the moment, looking over the topic I see that I did not mention this fact in this topic. TEDickey (talk) 11:37, 11 January 2012 (UTC)

The ncurses FAQ addresses some of these points in Why use terminfo instead of extensible termcap? TEDickey (talk) 11:43, 11 January 2012 (UTC)

OK, since it seems we all agree on these points, shall we move on and figure out how to include them? Tedickey, since you seem to be claiming some sort of quasi-owndership here, I defer to you, unless you want me to draft something. Old_Wombat (talk) 07:51, 12 January 2012 (UTC)

Suppose we discuss it here (my explanations are likely to be too detailed for the topic, so a draft from you with my pointing out issues might be a way to proceed) TEDickey (talk) 11:21, 12 January 2012 (UTC)

There are no WP:RS mentioned in any of Schily's edits. TEDickey (talk) 23:15, 30 January 2012 (UTC)

Many claims lacking reliable sources

The article contains a lot of claims that have never been verified and are just known by many people because they have been repeated many times.

Repeating unproven claims is however not what WP articles should rely on.

Let me give some examples: Termcap stores all information in a single flat file as human readable ASCII while Terminfo stores binary files in a directory hierarchy. The latter was faster in 1980 with the UNIX V7 filesystem used by AT&T but today it is definitely slower than reading a single large file. Given the fact that all entries of local importance have been moved to the top of the local termcap file and the fact that shells cache pre-parsed termcap files in their environment since more than 30 years, the claims about terminfo seem to be really outdated. Even the fact that the stack based cursor movement routine (the only real improvement in terminfo) may be better than termcap is no argument to prefer terminfo over termcap since the terminals that did need this feature have long gone into the junk yards and today people use emulated terminal windows that usually implement the ANSI control set. Schily (talk) 10:11, 19 August 2015 (UTC)

Let me add numbers to support my statements: system's vi on Solaris needs 4.5ms for the initial call to setupterm(), ved needs 2.5ms for the initial call to tgetent(). Both times fetched with truss(1m) library tracing, so this is far too much. Checking ved with specialized code shows that the whole terminal initialization (tgetent() + dozens of tgetnum()/tgetstr() calls) really takes 250 usecs and tgetent() alone takes 80 usecs. Terminfo is expected to take more than 350 usecs on the same machine as it needs to open a file which is avoided by termcap because of the TERMCAP environment from the shell. Schily (talk) 17:14, 19 August 2015 (UTC)

Finally, what is really important for speed is not the initial parsing speed at program startup but the quality of the implementation of the screen update function. This is really slow in emacs(1) (now based on terminfo), better in vi(1) (available in both flavors terminfo/termcap) and significantly faster in ved(1) that is termcap based. But even this is invisible to users with the computers from today as nobody uses a real ASCII terminal connected over a 9600 baud serial line anymore. Schily (talk) 10:31, 19 August 2015 (UTC)

As usual, you make a lot of remarks for which there is no reliable source. The set of "nobody" using real ASCII terminals is probably orders of magnitude larger than the extent "termcap users". You might consider spending some time looking for published sources which are relevant to your intent. TEDickey (talk) 23:38, 19 August 2015 (UTC)

By the way, your tags ignored the existing sources on the text, and you introduced an attack which has no published source (makes your edits appear like vandalism, so I trimmed it back). You might consider pointing out on the discussion page the parts which you feel are neglected -- but limited to remarks citing published sources, of course. TEDickey (talk) 23:42, 19 August 2015 (UTC)

Regarding "ved", the only well-known program with that name is the Poplog editor, which is unrelated to this discussion. If you want to bring some other "ved" into the discussion, you will have to cite a published source (no, SourceForge is not a publisher), so that we can limit the discussion to facts presented in that source. TEDickey (talk) 00:24, 20 August 2015 (UTC)

As usual, you don't give a constructive reply, you don't give reliable sources for your claims (that usually are in conflict with observable facts) and you confirm that you miss fact based knowledge on the topic. But we already know that you seem to miss important knowledge about UNIX in the time before 1990 and thus may not be able to understand that some of the modifications on UNIX introduced by AT&T (after splitting off USL) just serve the purpose to support the slow UNIX V7 filesystem that was in use by AT&T until the late 1980s. Those changes have been counter-productive with modern filesystems. The data structures in terminfo are such a relict from the 1970s that tried to fix problems from the past and terminfo would not be in widespread use if AT&T did not make vi 8-bit clean for SVr2 and at the same time converted it to use terminfo in a way that made a back-conversion hard. Sun did import this 8-bit clean vi fork from AT&T in 1986 and this is the main reason, why terminfo is in use today at all.

One of the useful results from "heirloom" is a 8-bit clean vi that is still termcap based, so you can link it against a terminfo based termcap emulation library or a modern real termcap implementation like libxtermcap and compare... guess what this proves? Correct, it starts up 30% faster when it is linked against libxtermcap and launched from a modern shell that caches a preparsed TERMCAP in it's exported environment. Such a shell is e.g. the recent maintained Bourne Shell with the command line history editor based on the ved user interface. Given that the TERMCAP caching technology was already available in 1980, I am not sure what purpose an incompatible terminfo could serve that could not be achieved by just introducing a new termcap entry name for enhanced cursor movement support. But as mentioned before, today the terminals that would need this feature are no longer in use.

BTW, as a hint: ved is even in the list of UNESCO software, so you may need to learn how to use a search engine. Come back once you are willing to have a fact based discussion. Schily (talk) 10:41, 20 August 2015 (UTC)

Once again, you follow your usual pattern: accuse others of being stupid and ignorant, not providing any reliable source to back up any of your comments. You have no facts. If you did, you might occasionally provide a reliable source of information. Your remarks reflect only upon you. TEDickey (talk) 00:18, 21 August 2015 (UTC)

By the way, I'm aware of the "list of UNESCO software" (better known as the Free Software Directory, which is essentially composed of rote copying from program descriptions, e.g., from pkgsrc (which in turn cuts/pastes descriptions from the package's README files). If you are suggesting that it be used as a source demonstrating notability, equally, you might consider noting your presence in the local telephone directory on your resume, if you have not already done so. (I have not, but tastes differ). Have a nice day. TEDickey (talk) 08:07, 21 August 2015 (UTC)

How to credit Mary Horton

Mary Ann Horton was very important to the development of this software, but most of this work was published under her deadname. MOS:DEADNAME suggests crediting the author like "Mary Horton (credited as Mark Horton)". But Horton is mentioned several times throughout the article, each time using the Deadname. If every instance of "Mark Horton" is changed to "Mary Horton (credited as Mark Horton)", it seems like that would draw excessive attention to Horton's gender identity, which seems contrary to the spirit of MOS:DEADNAME. Is there a better way to do this? Would it be acceptable to use "(credited as Mark Horton)" only the first time it's mentioned in this article, perhaps? I'm not aware of any guidance more specific than MOS:DEADNAME.