From owner-freebsd-current Wed Apr 10 14:19:50 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA10115 for current-outgoing; Wed, 10 Apr 1996 14:19:50 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA10096 for ; Wed, 10 Apr 1996 14:19:36 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02416; Wed, 10 Apr 1996 14:17:46 -0700 From: Terry Lambert Message-Id: <199604102117.OAA02416@phaeton.artisoft.com> Subject: Re: terminfo-less ncurses To: mike.long@analog.com Date: Wed, 10 Apr 1996 14:17:46 -0700 (MST) Cc: current@FreeBSD.org, ncurses-list@netcom.com In-Reply-To: <9604101609.AA23711@cthulhu> from "Mike Long" at Apr 10, 96 12:09:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >> > If you add attribute "foo", since the on disk data is a binary > >> > data file contatining a structure, all on-disk data files must be > >> > changes and all statically linked programs must be relinked to > >> > get the new sizof(struct) and element layout. > >> > > >> Now, *this* argument makes sense. > > I would think that old binaries would still work, if: > > 1) You always add new attributes to the *end* of the structure. Not possible if both Mike and Terry add new attributes for seperate projects. You are back to the patchkit "patch sequence number assignment" issue of enforced application ordering, and the need for a central repository to do the assigning, and the beaurocratic overhead each project then faces. > 2) Existing attributes (order and size) are not changed. More likely to be obeyed, but not absolute. Historically, size and ordering have both been changed. > 3) The library code only reads sizeof(struct) bytes, instead of > until EOF, when reading the compiled description (ncurses may > already do this). I think it does. > Old binaries will simply not read new attributes, but no memory > clobbering &c. should occur. They're using the old code, so they > wouldn't use any new attributes anyway. Unless they were something like a PERL interpreter. Then you are screwed. > >> I take it that in a termcap file, if you add attribute "foo" to one > >> entry, you don't have to do so to all the entries? Or is it just the fact > >> that its in one file instead of many? > > > >You are not required to add any particular attribute to any particular > >entry. This includes new attributes. > > > >The file format is not changed; since the attributes are interpretively > >parsed from the file, the name is less important than the format. > > > >The difference is that I can add as many attributes as I want without > >affecting any binary files (well, lookups are now done using an > >indexed database, but the principle is the same). > > Note, however, that you must watch out for the 1024-character > limitation. That can severely restrict your ability to add new > attributes. Yes, that's another limitation I dislike. > All that aside, I don't think it should matter which of the two > description formats you use. Zeyd and Eric think termcap sucks; > that's their opinion. Many BSD users disagree, and *WILL* *NOT* *USE* > ncurses unless it can use termcap instead of terminfo, no matter what > Bostic has said. I'm in this category. You can't murder termcap, the old but likable leader, to put in your puppet dictator. 8-). If they can coexist, fine, but I don't buy that terminfo is an acceptable replacement for termcap. For one thing, I abuse termcap horribly for things like /etc/printcap, /etc/disktab, and the new /etc/login.conf used by BSDI. We aren't talking about curses as the only consumer of the code, and we aren't talking about only reading terminal attributes (predefined terminal attributes at that). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.