The reason that "expect" is underappreciated is right there in the text: > most of the things that you could use expect for, are usually done much better using

The reason that "expect" is underappreciated is right there in the text: > most of the things that you could use expect for, are usually done much better using another method. Outside of it's very narrow use case (driving un-scriptable CLIs and automated tests for command-line tools, and maybe some exotic CLI-centered workflows), trying to use "expect" will often result in fragile code with surprising failure mode. In 2nd example, script will fail if user has non-default top's config. It also messes up terminal on exit. Use top's "personal configuration file" instead. In the 4th example, you are not just trapping Ctrl-D in bash, you are trapping it in all bash-spawned commands (like "cat >file"). I am going to guess that bash's native IGNOREEOF option was what the author wanted. In the 9th example (md5sum) , expect'll work fine -- but learning standard unix commands like "grep -m1" and/or "tee /dev/stderr" will allow many things that expect cannot, like doing an md5sum on millions of small files.