stty -echo doesn't work?

apologies if this has been posted before.

I just noticed that the following command

	$ stty -echo

does not work in an interactive dash(1) shell. Initially I thought it was an issue with my terminal but I tried in bash(1) as well and it works fine.

If this is a known issue and there is some work around (i.e., I'm doing something wrong?), I'd love to know how to fix it, but if it is a genuine bug I will take a look and send a patch if/when I fix it :)

Thanks!

S.

Hi,

stty is not a shell built-in command and dash has no control over what it does. 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. This seems to be intentional on the part of libedit, it resets the tty to a known good state when it knows it needs it, but I am not sure whether it is also intentional that that reset state persists after it has successfully read the next line.

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.

Cheers,
Harald van Dijk

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

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.

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.

Let's see if I can explain what other shells are doing.

The cat' behavior is consistent with how POSIX describes stty echo':

echo (-echo)
Echo back (do not echo back) every character typed. This shall have
the effect of setting (not setting) ECHO in the termios c_lflag field, as defined in XBD 11. General Terminal Interface.

So the echo' suboption only controls echoing of input. If dash, when using libedit and with editing enabled (e.g., set -o emacs'), restores echo when reading the command line, it would appear that libedit is forcing a known set of tty flags.

This is consistent with the above description: output is not suppressed, but input is not echoed.

If you were to change your example above to do something like

stty -echo
echo -n 'enter data: '
cat > foo
stty echo

You'll see that the `echo data: ' is visible, but user input is not, and the bash behavior is consistent with that.

It does.

Do you think that the editing library should honor the user's tty settings modified using stty', use its own internal sane' settings to provide consistent behavior, or use internal settings separate from the ones set using stty' but provide a shell builtin that allows users to modify those internal settings (e.g., tcsh's setty')?

All of these are reasonable choices that different shells have made. Readline, obviously, uses the first option.

I would argue otherwise, of course.

``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/

Thank you; this is the sort of stuff I meant when I said I felt like I needed to do more research, but you've done it for me.

Thank you for confirming :)

The only one of these that I really object to is the second (which is what libedit does), because it is the one (in my opinion) that is most suprising for the user. The first is maybe the simplest/cleanest (least suprise), again, in my opinion.

As you said, though, these are all reasonable choices, so this is decidedly not a bug in dash (or, rather, libedit), but just behaviour I was not expecting.

I really should have emphasized the _maybe_ in that comment. I really just didn't want to seem completely ignorant for expecting dash to behave the same as bash in the case that it (bash) was actually doing the wrong (but maybe more appealing) thing.

S.