[Karellen]

> A shell run via `sshd` is technically not an interactive shell, as it is started by the ssh-daemon.

Hmmm....I'm a bit confused by that one. Why is the program that started the shell an important consideration as to whether it should be considered interactive or not? Shouldn't it just be how the shell is most likely to be used?

Are shells started by `xterm` (and similar) "technically" interactive? What about shells started by `screen`/`tmux`? What makes them different to, or the same as, `sshd`?

[usrbinbash]

"Interactive" in this sense has less to do with how the shell is used, and more with how it is invoked and connected to it's environment.

From the manpage:

     An interactive shell is one started without non-option arguments
     (unless -s is specified) and without  the  -c option,  whose  standard
     input and error are both connected to terminals (as determined by
     isatty(3)), or one started with the -i option.

Technically, the shell isn't connected to a terminal when started by sshd but to the ssh connection. So yeah, from the point of view of the user, it is absolutely interactive, but not from the point of view of bashs internal logic.

[Karellen]

Huh. My intuition would have been that stdin/stderr provided by sshd to the shell would have been been marked as `isatty(3)`. TIL.

[usrbinbash]

The interesting thing is, `isatty()` seems to report 1 even over an ssh connection...so yeah, purely from that point of view, the shell should be "interactive". Why this case is then marked as special in the bash manpage, I cannot say :D