On Wed, Feb 6, 2013 at 12: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?
>
Agreed! Also, this may or may not even fix the problem. Now that you
describe this I realize I was assuming the problem was on the remote side.
If it was the remote side then the popen call will have nothing to do with
it since the /bin/sh is happening on the local side.
The layers should be ....
Local side: /bin/sh -> ssh
Remote side: /bin/tcsh -> fossil
I'd like to trick fossil into running "exec fossil" on the remote. It is
just wild speculation but stdin/out is going though the tcsh instance on
the remote and perhaps execing fossil will bypass the problem?
I tried:
blob_zero(&cmd);
blob_append(&cmd, "exec ", -1);
shell_escape(&cmd, g.urlFossil);
but get:
ssh -t -e none localhost
Pseudo-terminal will not be allocated because stdin is not a terminal.
************************************************
Use of this system by unauthorized persons or
in an unauthorized manner is strictly prohibited
************************************************
Authentication successful.
stty: standard input: Invalid argument
Broken pipe: 2 Artifacts sent: 0 received: 130
At least it doesn't hang :) . Any suggestions?
and the hypothesis is that svn and hg use the first approach which bypasses
>> whatever the issue is with tcsh?
>>
>> Aside, I read the man page but don't understand why "/bin/sh" is in the
>> call to execl twice. The second call seems to be running zCmd as a comand.
>> Is this to deal with shell escaping hell?
>>
>> execl("/bin/sh", "/bin/sh", "-c", zCmd, (char*)0);
>>
>
> That's the way execl() works. First argument is the filename of the new
> image. Second argument is argv[0]. Third argument is argv[1]. And so
> forth. There is no good reason to have argv[0] different from the filename
> of the new image - I think that capability is legacy.
>
Ah, now it makes sense. Thanks. It never occurred to me that argv[0] might
not actually be directly derived from the filename being executed.
> --
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
