Zsh Mailing List Archive
Messages sorted by:
Re: read -s
- X-seq: zsh-users 5245
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: DervishD <raul@xxxxxxxxxxxx>
- Subject: Re: read -s
- Date: Thu, 15 Aug 2002 12:57:17 +0100
- Cc: zsh-users@xxxxxxxxxx
- In-reply-to: <3D5B7B8C.mail12L17CVMQ@xxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <1029335491.21222.75.camel@carrot> <E17ezfU-00042N-00@xxxxxxxxxxxxxxxxxx> <3D5B7B8C.mail12L17CVMQ@xxxxxxxxxxxx>
- Sender: kiddleo@xxxxxxxxxx
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
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.
Messages sorted by: