Re: stty -echo doesn't work?

[Sebastien Peterson-Boudreau <sebastien.peterson.boudreau@gmail.com>]

> stty is not a shell built-in command and dash has no control over what it
> does.

I knew that, but this was still a behaviour I was only seeing in dash
and not other shells.

> Running this locally, what seems to be happening is that the command
> did work, but when dash is using libedit for command editing, it immediately
> gets reset when prompting for the next command.

I really should have done more thorough testing... You're right; I see
that echo is disabled when I try

	$ stty -echo; cat > foo

For the duration of cat(1) (IOW, until I hit ^D), the terminal does not
echo, but upon returning to the shell echo is restored.

> What behaviour are you expecting here? Are you expecting echo to still be
> turned off when entering the next command, or to be turned off again after
> the next command has been entered successfully? Both options, as well as
> dash/libedit's current behaviour, seem reasonable at first glance to me.

Assuming I am understanding the two options you list, I think what I
expected was the second? For bash, the user input is not echoed until
echo is restored with `stty echo', but the prompt is still printed
after each command is entered. To make myself extremely clear (not
because I don't think you're capable of understanding, but because I
don't think I'm capable of explaining...), I will do a lil diagram thing

	$ echo hi
	hi
	$ stty -echo
	$            # user types `echo not echoed', but it is not shown
	not echoed
	$            # user types `stty echo', but it is not shown
	$ echo hi again
	hi again

now that is what I _expected_ to happen, but that is based on bash's
behaviour, which is based on readline (what bash uses (I think?)). What
do I think _should_ happen? Well now I feel like I might need to do
some more research. Maybe this is a situation where bash does something
weird but we're all used to it.

Thanks for your detailed reply!
-- 
S.