bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ~/.bashrc not sourced for ssh commands on Archlinux


From: Bob Proulx
Subject: Re: ~/.bashrc not sourced for ssh commands on Archlinux
Date: Thu, 25 Apr 2013 18:09:45 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]