From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8056 invoked from network); 19 May 2003 14:54:12 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 19 May 2003 14:54:12 -0000 Received: (qmail 21060 invoked by alias); 19 May 2003 14:54:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18551 Received: (qmail 21046 invoked from network); 19 May 2003 14:54:03 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 19 May 2003 14:54:03 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [213.228.0.44] by sunsite.dk (MessageWall 1.0.8) with SMTP; 19 May 2003 14:54:3 -0000 Received: from pcchazelas.free.fr (grenoble-1-a7-62-147-73-141.dial.proxad.net [62.147.73.141]) by postfix3-1.free.fr (Postfix) with ESMTP id 07A0BC0FD for ; Mon, 19 May 2003 16:54:02 +0200 (CEST) Received: (from chazelas@localhost) by pcchazelas.free.fr (8.9.3/8.9.3) id QAA19533 for zsh-workers@sunsite.dk; Mon, 19 May 2003 16:51:10 +0200 Date: Mon, 19 May 2003 16:51:09 +0200 From: Stephane CHAZELAS To: Zsh hackers list Subject: Re: echoti and number of arguments Message-ID: <20030519165108.D129@pcchazelas.free.fr> Mail-Followup-To: Zsh hackers list References: <20030517100115.A128@pcchazelas.free.fr> <6877.1053340085@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.14i In-Reply-To: <6877.1053340085@csr.com>; from pws@csr.com on Mon, May 19, 2003 at 11:28:05AM +0100 On Mon, May 19, 2003 at 11:28:05AM +0100, Peter Stephenson wrote: > Stephane CHAZELAS wrote: > > I've noticed that the number of arguments was checked with > > echoti. It's not a good idea. > > I think we need a configure test to make sure tparm() can take nine > arguments to make sure we don't get into compatibility problems. That > will depend on various curses-style things, c.f terminfo.mdd. More than that, tparm can take 0 to 9 parameters, which can be of type "int" or "char*" and it's the responsability of the caller to provide enough arguments and of the right type. For instance TERM=hpterm echoti pfx 1 "test" Should call tputs(tparm(tigetstr("pfx"), 1, "test"),1,putraw) and to know that the second parameter is not a number, well, two approaches: 1- parse tigetstr("pfx") => hard to do and redondant with what tparm() already does. 2- hard code the few existing capabilities that accept non-integers (that's what ncurses' tput(1) does using this table: TD(Num_Str, "pkey_key", "pfkey", "pk"), TD(Num_Str, "pkey_local", "pfloc", "pl"), TD(Num_Str, "pkey_xmit", "pfx", "px"), TD(Num_Str, "plab_norm", "pln", "pn"), TD(Num_Str_Str, "pkey_plab", "pfxl", "xl"), The problem with that approach is the lack of extensibility. But, for the probably limited usage of echoti in zsh, that's probably far enough (and there already are hardcoded capnames in Modules/terminfo.c). For other capabilities, tparm() should be called with 9 numeric arguments (non-provided ones defaulting to 0). Note that actually zsh's "bin_echoti" is quite bogus. I've spent several minutes wondering how the "tputs(tparm(t, atoi(*argv)), num, putraw)" could work with "cup" while we are actually passing only one parameter to tparm(). It seems to be due to some side effect of the va_list processing (I guess tparm() actually takes "num" as its second parameter somewhere on some stack), if I change it to z= tparm(t, atoi(*argv)); tputs(z, num, putraw), it doesn't work anymore. Note that there are problems with echotc too when libtermcap is ncurses. For instance, when you do a tgetstr("AB"), you actually get the terminfo entry for "setab", in terminfo format. So, the routine used to count the number of expected arguments doesn't work either (as you don't have a termcap format). Note that tcsh's echotc is fooled on that one too. $ echotc AB 1 echotc: not enough arguments (my setab is \E[%?%p1%{8}%<%t%p1%'('%+%e%p1%{92}%+%;%dm, which anyway cannot be mapped to termcap format). -- Stéphane