From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13789 invoked from network); 30 May 2001 14:01:31 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 May 2001 14:01:31 -0000 Received: (qmail 5723 invoked by alias); 30 May 2001 14:01:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14569 Received: (qmail 5704 invoked from network); 30 May 2001 14:01:24 -0000 Date: Wed, 30 May 2001 10:00:01 -0400 From: Clint Adams To: Andrej Borsenkow Cc: ZSH Workers Mailing List Subject: Re: termcap bug on Linux Message-ID: <20010530100001.A27922@dman.com> References: <1010529160507.ZM13557@candle.brasslantern.com> <000001c0e8d1$33b431b0$21c9ca95@mow.siemens.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000001c0e8d1$33b431b0$21c9ca95@mow.siemens.ru>; from Andrej.Borsenkow@mow.siemens.ru on Wed, May 30, 2001 at 10:24:37AM +0400 > Yes. About scantermcap - I am not sure. Currently it returns "no" for both > unexisting and unset flags; if we change this as well, it will return > nothing for unexisting flags. I am not sure how useful $termcap is at all, > given that there is no way to associate returned values with capabilities. > Two possible valid usages are ${(k)termcap} or ${(kv)termcap}. For > consistency, I'd suggest to change scantermcap as well but I do not > insist.Clint? I'm fine with the consistency. I just think that an unconditional reliance on NCURSES_VERSION being set is going to lead to trouble.