From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11476 invoked from network); 15 Aug 2002 11:58:03 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 15 Aug 2002 11:58:03 -0000 Received: (qmail 12364 invoked by alias); 15 Aug 2002 11:57:49 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5245 Received: (qmail 12350 invoked from network); 15 Aug 2002 11:57:48 -0000 X-VirusChecked: Checked In-reply-to: <3D5B7B8C.mail12L17CVMQ@viadomus.com> From: Oliver Kiddle References: <1029335491.21222.75.camel@carrot> <3D5B7B8C.mail12L17CVMQ@viadomus.com> To: DervishD cc: zsh-users@sunsite.dk Subject: Re: read -s MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17448.1029412542.1@logica.com> Date: Thu, 15 Aug 2002 12:57:17 +0100 Sender: kiddleo@logica.com Message-Id: On 15 Aug, you wrote: > >I expect it would be fairly easy to add this -s option to the read in zsh. > >Does anyone think it would be worth doing? > > IMHO the stty solution is cleaner and more portable. BASH is > bloated with things like those, please don't imitate ;)) Well Peter has already posted a patch for it on -workers though he hasn't committed it to CVS. The patch isn't big enough to upset me as being bloat but I can see your point. If it doesn't go in, it might be a good idea to add the stty trick to the FAQ instead. Incidentally, in ksh93, the -s option to read adds the line to the history. Not that I'd suggest copying that particularly because the read can always be followed by a print -s and because I'd tend to use vared instead of read in such circumstances anyway. >>From the bash/ksh compatibility perspective, what might be useful would be to add the -d option to read which both ksh93 and bash have. It lets you specify a delimiter to stop reading at (instead of newline). > For example, bash has a non-POSIX, non-SuSv3 compliant > implementation of 'printf' builtin, and zsh has one fully compliant, > and this is applicable to more builtins. The '-s' flag to read is not > necessary at all. UNIX has this policy (IMHO, again): keep it simple > and divide the tasks among processes instead of bloating one of them. Out of interest, in what way is bash's printf non-compliant? Also, zsh 4.0.x does not have a printf builtin. The printf in the 4.1 branch is compliant to my knowledge but adds a good few features which go beyond the standards. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.