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. — Preceding unsigned comment added by Gnebulon (talk • contribs) 13:43, 16 October 2021 (UTC)

The problem with your intended edit is that there are no technical references using the so-called "live name". All of the relevant technical work was done at least 10 years earlier. TEDickey (talk) 13:48, 16 October 2021 (UTC)

"Horton" after the first appearance. 81.187.27.126 (talk) 18:35, 30 October 2021 (UTC)

My reading of of the MOS is that, generally, mentioning the former name is only appropriate once, in the lede. "Name and gender matters should be explained at first appearance in that article, without overemphasis". So I have done that. It seemed appropriate to mention the deadname in the citation, since people looking that up will need the name which was used at the time. I had to bodge that rather. If someone knows a better way to do this please do step up :-). Ijackson (talk) 19:34, 30 October 2021 (UTC)

The MOS doesn't tell editors to revise historical information and make up facts on talk-pagers. It's only relevant going forward. TEDickey (talk) 19:38, 30 October 2021 (UTC)

@Tedickey: you're mistaken. Please take another read of the MOS. It says:

Outside the main biographical article, generally do not discuss in detail changes of a person's name or gender presentation unless pertinent. Where a person's gender may come as a surprise, explain it on first occurrence, without overemphasis. Avoid confusing constructions (Jane Doe fathered a child) by rewriting (e.g., Jane Doe became a parent). In articles on works or other activity by a living trans or non-binary person before transition, use their current name as the primary name (in prose, tables, lists, infoboxes, etc.), unless they prefer their former name be used for past events. If they were notable under the name by which they were credited for the work or other activity, provide it in a parenthetical or footnote on first reference; add more parentheticals or footnotes only if needed to avoid confusion.

So in absence of a stated preference from Horton for the contrary, their current name is their primary name in this article. I don't see a reason to repeat the name outside the first mention. For the name in the reference itself, what Ijackson did seems to be the best solution per the MOS.

In source citations, do not remove names of authors, or references to former names in titles of works. If the author is notable, the current name may be given, for example as "X (writing as Y)". Do not replace or supplement a person's former name with a current name if the two names have not been publicly connected and connecting them would out the person.

Nil Einne (talk) 12:35, 31 October 2021 (UTC)

Revising the citation as recently done makes this a Wikipedia-only fact. If you want to have a reliable source to support that, making arrangements with the 'Usenet' organization to change their documentation seems a plausible approach. By the way, the other editor appears to be asserting that I have recently reverted the current set of changes to this topic. That's harrassment. TEDickey (talk) 13:09, 31 October 2021 (UTC)

We have an article Mary Ann Horton supported by a number of reliable sources. There is no possible dispute that Mary Horton is the current name of the person. From what I can tell, no one has claimed you reverted the most recent change. What User:Ijackson has said, correctly, is that you've been preventing the article being brought into line with MOS:GENDERID by continually reverting until now. Since this is a BLP matter, you've also been preserving a BLP violation for several years. While is is unfortunate that no one pointed to the correct guideline until now, it is your responsibility as an editor to familiarise yourself with our policies and guidelines at least to the extent that you do not commit BLP violations. Since we do not WP:PUNISH editors here, provided you stop and don't repeat your violations, no action will be taken against you. But this doesn't change the fact you've preserved a BLP violation for over 3.5 years [1]. And so it was perfectly fine for an inexperienced editor to seek help at BLPN being concerned you might not stop and also needing help if you did not stop. If you don't want editors to raise concerns about your editing, then don't violate BLP for 3.5 years. (N.B. While it's true things were less clear before the recentish RfC Wikipedia talk:Manual of Style/Biography/2021 archive#RfC: Changing MOS:DEADNAME on how to credit individuals on previously released works, it's been a long time since the correct solution was simply to not mention the current name at all for a notable person with an article we are linking to.) Nil Einne (talk) 13:53, 31 October 2021 (UTC)

I don't follow your argument here. For the avoidance of doubt: Your repeated citation of WP:RS is not appropriate and does not justify your edits. The page history here shows multiple people correcting your wrong edits, but you keep changing them back. I have reviewed the WP dispute resolution and escalation processes and it looks like some of these processes may be needed. For now I have made a report at Wikipedia:Biographies_of_living_persons/Noticeboard#Terminfo. Ijackson (talk) — Preceding undated comment added 20:20, 30 October 2021 (UTC)