Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-spam!mordor!lll-lcc!pyramid!prls!mips!dce
From: dce@mips.UUCP
Newsgroups: comp.bugs.4bsd
Subject: Re: Curses Bug
Message-ID: <233@quacky.mips.UUCP>
Date: Fri, 27-Mar-87 10:23:28 EST
Article-I.D.: quacky.233
Posted: Fri Mar 27 10:23:28 1987
Date-Received: Sat, 28-Mar-87 15:04:44 EST
References: <233@sering.mcvax.cwi.nl>
Reply-To: dce@quacky.UUCP (David Elliott)
Distribution: world
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 37

In article <233@sering.mcvax.cwi.nl> denise@sering.UUCP (Denise L. Draper) writes:
>Index:	/usr/src/usr.lib/libcurses/cr_tty.c
>
>Description:
>	Curses writes to a pointer that points to the static environment
>	variable TERM.  This can cause problems if an exec is then done.
>
...
>	The crucial feature is that the variable TERM must be shorter than
>	the 2nd terminal name in the appropriate TERMCAP entry (another
>	bug, I think: the function longname in curses claims to find the
>	long name of the terminal, while in fact it simply finds the 2nd
>	name).

The idea of "longname" is that a termcap entry is supposed to look
like:

	xx|longname|other aliases:...

It isn't the longest name, but the "most common" name for the terminal.
Finding the longest text string is not particularly useful, since that
string will almost always have spaces in it.

The result of longname() is correct.

Of course, the fix given is correct, and fixes more than just the
exec() problems. We had a user here that complained (and rightly so)
that no program should change the value of the TERM variable unless
that is part of its job. In this specific case, the program was a
bug report form editor, which at times would execute the user's editor.
In this case, the editor was emacs, and the user had programmed it
in such a way that it knew about specific values for TERM, none of
which were the "longname" value.
-- 
			David Elliott

UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD:  	408-720-1700