read -s

read -s

[Oliver Sturm]

Hi!

In bash, I can do "read -s" to emulate a password prompt without any
echoing. Is there some way to do the same in zsh? The -s or a similar
parameter isn't supported, is it? Is there an external command that I
don't know? Thanks for any input!


                       Oliver Sturm

-- 
Fa. Manfred Dahlhoff - Buellenkothenweg 37a - 40229 Duesseldorf
Tel.: 0211-2202821   - Fax: 0211-2202822    -
http://www.Manfred-Dahlhoff.de

Re: read -s

[Oliver Kiddle]

On 14 Aug, you wrote:
> 
> In bash, I can do "read -s" to emulate a password prompt without any
> echoing. Is there some way to do the same in zsh? The -s or a similar
> parameter isn't supported, is it? Is there an external command that I
> don't know? Thanks for any input!

You can use stty to turn off echoing. Like this:

stty -echo
read password
stty echo

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?

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.

Re: read -s

[Oliver Sturm]

On Wed, 2002-08-14 at 17:02, Oliver Kiddle wrote:

> > In bash, I can do "read -s" to emulate a password prompt without any
> > echoing. Is there some way to do the same in zsh? The -s or a similar
> > parameter isn't supported, is it? Is there an external command that I
> > don't know? Thanks for any input!
> 
> You can use stty to turn off echoing. Like this:
> 
> stty -echo
> read password
> stty echo

Great, that works for me. Thanks!


                       Oliver Sturm

-- 
Fa. Manfred Dahlhoff - Buellenkothenweg 37a - 40229 Duesseldorf
Tel.: 0211-2202821   - Fax: 0211-2202822    -
http://www.Manfred-Dahlhoff.de

Re: read -s

[DervishD]

    Hi Oliver :)

>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 ;))

    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.

    Raúl

Re: read -s

[Oliver Kiddle]

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.

Re: read -s

[DervishD]

    Hi Oliver (Kiddle) :))

>>     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.

    Really, the patch is very small, and moreover Z sh is very well
coded (so it will difficult to bloat ;))))). Really, Zsh is not
bloated at all (IMHO), and the modular approach makes even more
difficult to bloat. For example, it has an ftp client, and if forced
it would be bloat (an ftp client on a shell...), but just making it a
module solves the problem. A very good job, indeed :)

>>     For example, bash has a non-POSIX, non-SuSv3 compliant
>> implementation of 'printf' builtin
>Out of interest, in what way is bash's printf non-compliant?

    The 'printf' builtin of BASH gives an error if you print, for
example, '--'. It interprets it as an option given... SuSv3 says that
printf must print whatever you pass as parameter.

>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.

    But won't choke on 'printf --' ;)) And it's true, zsh 4.0.x
doesn't have a printf, sorry. Bad example chosen here O:)) It was
/bin/printf that was invoked, from sh-utils (that, BTW, aren't
compliant. It won't print '--help', for example.

    Raúl

Re: read -s

[Chet Ramey]

> >>     For example, bash has a non-POSIX, non-SuSv3 compliant
> >> implementation of 'printf' builtin
> >Out of interest, in what way is bash's printf non-compliant?
> 
>     The 'printf' builtin of BASH gives an error if you print, for
> example, '--'. It interprets it as an option given... SuSv3 says that
> printf must print whatever you pass as parameter.

This is not correct.

In http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html:

The `OPTIONS' section of the printf description says `None'.

http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap01.html#tag_01_11
describes what this means:

Default Behavior: When this section is listed as "None.", it means
that the implementation need not support any options.  Standard
utilities that do not accept options, but that do accept operands,
shall recognize "--" as a first argument to be discarded. 

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )

Chet Ramey, ITS, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/