Ilya Basin wrote: > > There is a compile time option to cause bash to check for the > > SSH_CLIENT[2] environment variables but it seems arch doesn't > > enable it for its build.
And that has been a contentious issue. Some people like it. Some people hate it. If you don't have it then people file bugs to enable it. If you do have it then people file bugs to disable it. And correcty determining whether it should be done is not trivial. Really the biggest problem is that it isn't consistently implemented everywhere one way or the other. > Socket? How could it ever be connected to a socket, if the data has to > be decrypted first? A socket is like a pipe. Virtually the same thing. The alternative is a pty device. A pty is a pseudo-tty device. A pty is virtually the same thing as a tty device. Ssh will always open a socket between the two end points to transmit the data. How else would the data be transmitted? Then ssh will open *either* a pty *or* a socket/pipe to the shell depending upon things like the presence of a tty on input or the forcing with -t. (T for tty, even though it will open a pty, it is virtually the same thing). The important thing is that the bash process and all of the processes it launches will be using that connection for stdin, stdout, and stderr. A pty will have a tty line driver behind it, will have raw and cooked modes, and ioctl calls to set up the terminal for libreadline (think stty) will work. A socket/pipe will not and calls to ioctl to make line modifications will fail since it does not have a line driver behind it. Bob
