Feature request: fsh-like functionality

[Wout Mertens]

You can use bash co-processes to keep a link to the remote shell open and execute commands:

http://www.gnu.org/software/bash/manual/html_node/Coprocesses.html

Wout.

On Jul 23, 2010, at 13:05 , Norbert Nemec wrote:

> On 23/07/10 10:33, Wout Mertens wrote:
>> On Jul 23, 2010, at 11:14 , Norbert Nemec wrote:
>> 
>>   
>>> On 23/07/10 09:50, Norbert Nemec wrote:
>>>     
>>>> Hmm - based by these numbers I did some further test and am now suspecting that it is actually the login process of the bash that is eating up the time. Unfortunately, I cannot easily simplify the login scripts as a number of modules needs to be loaded. Furthermore, it is not quite clear to me which scripts are actually executed when calling 'ssh somehost "command"'. According to the documentation "command" is executed instead of a login shell. Still, the .bashrc seems to be read.
>>>>       
>>> Update: The real problem are /etc/bash.bashrc and /etc/profile -- both files are very complex and take significant time to process. I have no influence on the setup of the system. SSH does not seem to offer any way to issue a command without calling either of these two files. Am I missing something?
>>>     
>> Try calling a command with a full path and without special shell characters, I think SSH will then execute that directly. Try tracing execs from sshd on the receiving end?
>>   
> I checked the OpenSSH sources. Turns out that in session.c the sshd daemon actually *always* uses the login shell to interpret the command.
> 
> Turns out that furthermore, the bash tries to be smart and get in the way: /etc/bash.bashrc and ~/.bashrc are usually read only for interactive shells, not for shells that simply execute a command via the '-c' option. However -- bash automatically detects when it is called by rshd or alike. In this special case, it reads .bashrc anyways, with no way of switching off this behavior.
> 
> In most cases, I guess that this makes sense, because the environment would otherwise not be initialized. In my case, unfortunately, it means that a ssh command will always read /etc/bash.bashrc and will always take close to a second for it.
> 
> Unfortunately, this behavior is defined by sshd which I, as a user, have no control over. Guess, FSH remains the best workaround after all...
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100723/3da22b07/attachment-0001.bin>