On Wed, Feb 6, 2013 at 2:27 PM, Richard Hipp <d...@sqlite.org> wrote:
>
>
> On Wed, Feb 6, 2013 at 2:18 PM, Matt Welland <estifo...@gmail.com> wrote:
>
>> Hmmm... your point about the remote login is curious. I assumed that
>> fossil was doing something like this (I'm using faux code here):
>>
>> inport, outport = popen2("ssh", "-e", "none", "user@host", "fossil", ...
>> )
>>
>> but it sounds like what is actually being done is (I have not grokked the
>> code well enough to confirm yet) the following:
>>
>> inport, outport = popen2("ssh", "-e", "none", "user@host", "/bin/sh")
>> ...
>> print outport "fossil ... params"
>>
>
> Fossil needs to run multiple commands. /bin/sh is convenient to do this.
> If that is a really serious problem for the occasional csh system, then we
> could, in theory, create a new fossil command to take care of that for us:
> "fossil test-sh". Then run:
>
> popen2("ssh", "-e", "none", "user@host", "fossil", "test-sh");
>
> It seems silly to have to duplicate the functionality of /bin/sh inside of
> Fossil though, doesn't it?
>
>
I agree that it's look silly, but doing so would connect directly
stdout/stdin of local fossil to stdin/stdout of remote fossil avoiding any
interference caused by the shell or any login text.
When ssh directly call "fossil test-sh" on the remote side, *only* output
of this command will come from the stdout. When /bin/sh or no command is
used, there's no guaranties that no extra output from shell, motd, etc..
will not appear.
<snip>
--
Martin G.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
