Every once in a while I will do something like
ssh user@host sudo thing
and I am reminded that ssh doesn't allocate a pseudo-tty by default. Why doesn't it? What benefits would I be losing if I aliased
The primary difference is the concept of interactivity. It's similar to running commands locally inside of a script, vs. typing them out yourself. It's different in that a remote command must choose a default, and non-interactive is safest. (and usually most honest)
I would caution against using
You can also test for the presence of a terminal in your own shell scripts. To test STDIN with newer versions of bash:
Here is the same bash test as earlier, but for STDOUT:
While it's possible to work around these issues, you're inevitably going to forget to design scripts around them. All of us do at some point. Your team members may also not realize/remember that this alias is in place, which will in turn create problems for you when they write scripts that use your alias.
This allows you to get a "shell" of sorts to the remote server. For servers that do not grant shell access but allow SSH (i.e, Github is a known example for SFTP access), using this flag will cause the server to reject your connection.
The shell also has all your environmental variables (like
Think about backward-compatibility.
The 2 primary modes of ssh are interactive-login with a tty, and specified-command without a tty, because those were the exact capabilities of
So the defaults were decided before ssh was born. Combinations like "I wanna specify a command and get a tty" had to be accessed with new options. Be glad that at least we have that option now, unlike when we were using