I agree, expect is less and less useful, many vendors provides ways to automate deployment now. But "unautomatable" deployment is still happening. In some case

I agree, expect is less and less useful, many vendors provides ways to automate deployment now. But "unautomatable" deployment is still happening. In some cases you can deal with it with some "printf 'line1\nline2\n'| vendor_command", but the vendor command may ignore stdin and you have to use expect. Having to automate that way is extremely brittle, stdout and stdin are very poor and unstable APIs. For example I remember some internationalized installers which gave stdout outputs according to your locales (lesson learned, export LC_ALL=en_US.utf8 before an expect script). And if one message is added or is changed, it can break... Personally, I tend to repackage badly shipped software (yay installanywhere crap...) in deb or rpm files, at least that way, I encounter issues before I deploy in production and I can update/remove this software easily and completely. However, it only solves part of the problem, if the configuration steps are interactive only, you've to resort to expect in production. Expect is less and less useful, it's a last resort solution, but when you need it's extremely helpful.