stty -echo doesn't work?

stty -echo doesn't work?

[Sebastien Peterson-Boudreau]

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.

Re: stty -echo doesn't work?

[Harald van Dijk]

On 23/04/2026 03:39, Sebastien Peterson-Boudreau wrote:
> 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.

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

Re: stty -echo doesn't work?

[Sebastien Peterson-Boudreau]

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

Re: stty -echo doesn't work?

[Chet Ramey]

[-- Attachment #1.1: Type: text/plain, Size: 3493 bytes --]

On 4/23/26 5:36 PM, Sebastien Peterson-Boudreau wrote:
>> 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.

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

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

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

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.


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

It does.

> What
> do I think _should_ happen? 

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.

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

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    chet@case.edu    http://tiswww.cwru.edu/~chet/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: stty -echo doesn't work?

[Sebastien Peterson-Boudreau]

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

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.

> > 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?)).
> 
> It does.
> 

Thank you for confirming :)

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

> > 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.
> 
> I would argue otherwise, of course.

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.