I seem to be observing conflicting evidence regarding how the tty and the shell share responsibility for displaying user input.
In the following interactive session, user input is no longer echoed to the terminal, suggesting that the tty performs the echo.
$ stty -echo
# I typed ls (not displayed) and we see the output of ls only:
Bash.log File1 TTY.log
On the other hand, if we use expect to log exactly what is being emitted by bash vs by the tty, we can see that bash seems to be sending the user's input ls to the tty.
#!/usr/bin/env expect
spawn bash
log_user 0
set log_tty_fd [open "TTY.log" "w"]
set log_bash_fd [open "Bash.log" "w"]
expect {
-i $spawn_id "?" {
send_user -- [set expect_out(0,string)]
puts -nonewline $log_bash_fd [set expect_out(0,string)]
exp_continue
}
-i $tty_spawn_id "?" {
send -- [set expect_out(0,string)]
puts -nonewline $log_tty_fd [set expect_out(0,string)]
exp_continue
}
}
[?2004h~/Play4/X ls
[?2004l
Bash.log File1 TTY.log
[?2004h~/Play4/X exit
[?2004l
exit
ls
exit
When user input is echoed by the tty vs bash, and how do they coordinate so we (usually) see only one copy of user input if they both sometimes do it?
Echoing can be done either by the tty driver or the interactive application (e.g. a shell).
Normal echoing is done in the tty driver. But this provides only very simple editing: deleting the last character and erasing the entire input line. This is what you get when the terminal is in "cooked" mode and you have stty echo enabled, which is the default for login terminals. When you're entering a password, echo is turned off, but cooked mode still allows simple editing, you just can't see what's happening.
But some applications want to provide more advanced editing, usually patterned after the Emacs or vi editors -- you can move around in the line with arrow keys, recall previous inputs, etc. This is usually found in interactive applications that operate using a command prompt, and interactive shells are the most common of these.
These applications put the tty driver in "raw" mode, and process the inputs by themselves character by character. They turn off the tty driver's echoing, and do it themselves. Very often they make use of the popular readline library for consistency. This library allows for user customization of editing and shortcut keys using a .inputrc configuration file.
So either the driver does the echoing or the application does, but they shouldn't both do it. That's why you don't see doubled echoing. Where you sometimes run into this is in Emacs shell buffers. Emacs usually puts the tty used for these buffers into -echo mode, but some applications turn echo back on unconditionally. When this happens, you type a command into the shell buffer, and when you press Enter you see the command repeated.
As far as Expect is concerned, I don't think it should make a difference. It just sees what it receives on the master end of the pty, which is the same as what a human user sees on the terminal as they're typing. It can't distinguish output generated automatically by the tty driver from output written by the process at the other end of the pty.
In a regular interactive shell session, it’s the kernel’s TTY line, not the shell, that echoes each key you type. Whether or not your keystrokes appear on the screen depends entirely on the ECHO flag, which you can control with stty echo or stty -echo. When you turn echo off, the kernel stops sending typed characters back to the terminal. Bash still receives the input and runs commands, but nothing is shown as you type.
Bash itself doesn’t echo your keystrokes. Instead, it relies on the TTY for that. From what I understand its the readline library and the print are prompts and full command lines after you press Enter.
To avoid double echoing, programs choose one approach or the other. A typical shell leaves ECHO on and lets the TTY handle character-by-character input display. Programs like full screen editors or password prompts disable ECHO and take full control of how input is shown or hidden. So therefore between Bash and TTY, is why you normally see exactly one copy of your input, and why turning off ECHO hides it completely.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With