Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Because Ctrl+W is provided by something called TTY, and the other three are provided by the shell

This is more complicated (or simpler?) than what the article explains. Or I might be really confused. But if you strace bash while typing in stuff, you see clearly that it is reading in characters one by one, including ^W, and handling them itself. I don't see TTY doing much magic here at all:

    read(0, "h", 1)                         = 1
    write(2, "h", 1)                        = 1
    read(0, "e", 1)                         = 1
    write(2, "e", 1)                        = 1
    read(0, "l", 1)                         = 1
    write(2, "l", 1)                        = 1
    read(0, "l", 1)                         = 1
    write(2, "l", 1)                        = 1
    read(0, "o", 1)                         = 1
    write(2, "o", 1)                        = 1
    read(0, " ", 1)                         = 1
    write(2, " ", 1)                        = 1
    read(0, "w", 1)                         = 1
    write(2, "w", 1)                        = 1
    read(0, "o", 1)                         = 1
    write(2, "o", 1)                        = 1
    read(0, "r", 1)                         = 1
    write(2, "r", 1)                        = 1
    read(0, "l", 1)                         = 1
    write(2, "l", 1)                        = 1
    read(0, "d", 1)                         = 1
    write(2, "d", 1)                        = 1
    read(0, "\x17", 1)                      = 1     <-- bash reading in ^W!
    write(2, "\x08\x08\x08\x08\x08\x1b\x5b\x4b", 8) = 8


stracing bash more reveals another thing; when executing command like stty then before forking bash calls TCSETSW ioctl to set tty settings, and after child exists its calls TCSETSW again to set its own values, so stty does not actually show what mode the tty is in while bash is handling the input:

    ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0
    clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fe653abef10) = 5175
    wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED|WCONTINUED, NULL) = 5175
    --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=5175, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
    wait4(-1, 0x7fff156cbad0, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD (No child processes)
    ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
https://man7.org/linux/man-pages/man4/tty_ioctl.4.html


I wish it would fully reset the terminal mode after every command though so you don't get stuck without seeing what you type when some CUI program terminates without cleaning up properly. That's why I have `stty sane` in my PROMPT_COMMAND.


I believe this is handled by the tty "canonical" (line input) mode. If you run "stty -a" you'll see a number of special characters defined, like werase = ^W

If you set this to something else (stty werase ^O) you'll see it takes effect immediately.


but as it turns out bash does not use canonical mode, and I suspect that applies to many other interactive repls/shells too; probably something readline handles


You are correct for bash. If you run "cat" (from "bash"), you'll see that it no longer handles control-A or control-E (handled by readline...), but control-W is still handled by the tty.


Interesting.

Also if you disable werase i.e. "stty werase ''" and use the bind bash builtin to set "bind Control-w:' backward-kill-word'" you will get slightly different behaviour. A hyphen will be considered a word ending, unlike the tty.

So does bash read ^w and mimics the tty behaviour regarding the definition of a word?

I don't have linux handy right now and tracing on macos is painful otherwise I'd dive deeper.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: