Re: [fossil-users] ssh transport and tcsh
It looks like trying to override both the shell and the fossil
location works only for the initial clone. There is a problem with
using to separate the second parameter so a sync done later fails.
/opt/bin/fossil remote-url
'ssh://localhost:22///tmp/fossils/testing.fossil?fossil=/opt/bin/fossilshell=/usr/bin/bash'
Everything after the seems not to be stored by fossil.
For now I use the fossil I compiled where I forced the shell. Can the
remote-url storage escape the or is there an alternate character
that can be used?
On Wed, Feb 6, 2013 at 7:05 PM, Matt Welland estifo...@gmail.com wrote:
On Wed, Feb 6, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Feb 6, 2013 at 6:22 PM, Matt Welland estifo...@gmail.com wrote:
I got some help from a co-worker to test this fix. He ran 1000's of clones
with bash as a login shell and with tcsh as a login shell with zero
problems. Can a couple other folks test it and can it then get into the
official release (assuming no problems found)?
It would be a real boon for me and some of my co-workers to have this
working :)
I want to understand the problem before I put in the fix.
To try to help better understand what is happening, I have added a new query
parameter to the ssh: url scheme. You can now say:
fossil clone ssh://user@host/path/to/repo?shell=/bin/bash new.fossil
and that will cause Fossil to add the /bin/bash argument to the end of the
ssh command. Please note that you can also do --sshtrace to get some
interactive information on what the ssh command is doing.
This idea seems good to me. I'll test it tomorrow. Thanks!
On my debian system, the clone hangs with shell=/bin/tcsh and with
shell=/bin/sh but works with shell=/bin/bash. Except if I also add the
--httptrace argument, then all three work. The --httptrace argument
disables compression of the content moving over the wire. So perhaps the
problem is that with compression turned on you occasionally get binary 0x00
bytes moving over the wire, which confuses /bin/tcsh and /bin/dash but not
/bin/bash. Just a guess.
I did try stty raw thinking it might be xon/xoff or other
handshaking but got errors with the command.
Note that you have long had a query parameter
fossil=/path/to/fossil/on/remote/system with the ssh: scheme that lets you
specify a particular version of fossil to run on the remote system. At
least on my machine, my fossil binaries is not on the path set up by .cshrc,
so I also have to manually specify the location of the fossil binary if I
change from using /bin/bash.
Yep, I used the ?fossil= to do my testing. This approach with the
query parameters is very useful.
Cheers,
Matt
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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
--
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
Re: [fossil-users] ssh transport and tcsh --off topic
On Thu, 07 Feb 2013 00:05:48 +0100, Richard Hipp d...@sqlite.org wrote: On my debian box, /bin/sh is a symlink to /bin/dash (which I have never heard of before). `dash' is the 'debian almquist shell': http://en.wikipedia.org/wiki/Debian_Almquist_shell (and also http://en.wikipedia.org/wiki/Almquist_shell) which is nowadays used as a dropin replacement for the original bourne shell in all system scripts since it is way faster than bash which was used previously (I blieve that's why the respective boxes are booting much faster these days...) -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssh transport and tcsh
On Wed, 06 Feb 2013 18:48:01 +0100, Matt Welland estifo...@gmail.com wrote: Using ssh for transport still doesn't work if a users login shell is tcsh. I'm looking for help on this problem as I've not yet found a solution. If anyone can confirm that the problem exists or if anyone has yes, I can confirm this (ssh transport not working with `tcsh'), both, under Ubuntu and MacOSX. matter of taste whether this is a `fossil' problem or a `tcsh' problem. I believe it has to do whith the fact that fossil actually is doing a remote login (not just executing a command via ssh as `svn' and `hg' are doing if I understand correctly). maybe with a little help from the developers the problem could be narrowed down somewhat and then brought to the attention of the tcsh maintainers? suggestions or insights as to what the problem might be it'd be much appreciated. To reproduce on Ubuntu just do the following: 1. Test ssh. The following command should complete without prompting for a password (you may get the authentication popup just once): ssh localhost ls 2. Test with bash (this assumes your default shell is /bin/bash which on 99% of sane Linux systems it is. This command would clone ~/foo.fossil to ~/new.fossil fossil set ssh-command 'ssh -e none' fossil clone ssh://$USER@localhost//home/$USER/foo.fossil?fossil=/home/$USER/bin/fossil new.fossil 3. Test with tcsh sudo apt-get install tcsh chsh -s /bin/tcsh # Repeat the clone above after removing new.fossil The clone in step three will succeed some of the time but fail most of the time (it hangs). Thanks in advance. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssh transport and tcsh
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 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); On Wed, Feb 6, 2013 at 10:56 AM, j. van den hoff veedeeh...@googlemail.comwrote: On Wed, 06 Feb 2013 18:48:01 +0100, Matt Welland estifo...@gmail.com wrote: Using ssh for transport still doesn't work if a users login shell is tcsh. I'm looking for help on this problem as I've not yet found a solution. If anyone can confirm that the problem exists or if anyone has yes, I can confirm this (ssh transport not working with `tcsh'), both, under Ubuntu and MacOSX. matter of taste whether this is a `fossil' problem or a `tcsh' problem. I believe it has to do whith the fact that fossil actually is doing a remote login (not just executing a command via ssh as `svn' and `hg' are doing if I understand correctly). maybe with a little help from the developers the problem could be narrowed down somewhat and then brought to the attention of the tcsh maintainers? suggestions or insights as to what the problem might be it'd be much appreciated. To reproduce on Ubuntu just do the following: 1. Test ssh. The following command should complete without prompting for a password (you may get the authentication popup just once): ssh localhost ls 2. Test with bash (this assumes your default shell is /bin/bash which on 99% of sane Linux systems it is. This command would clone ~/foo.fossil to ~/new.fossil fossil set ssh-command 'ssh -e none' fossil clone ssh://$USER@localhost//home/$** USER/foo.fossil?fossil=/home/$**USER/bin/fossil new.fossil 3. Test with tcsh sudo apt-get install tcsh chsh -s /bin/tcsh # Repeat the clone above after removing new.fossil The clone in step three will succeed some of the time but fail most of the time (it hangs). Thanks in advance. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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
Re: [fossil-users] ssh transport and tcsh
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? 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. -- 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
Re: [fossil-users] ssh transport and tcsh
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
Re: [fossil-users] ssh transport and tcsh
On Wed, Feb 6, 2013 at 3:39 PM, Matt Welland estifo...@gmail.com wrote: 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 The command: ssh -e none user@host /bin/sh should cause /bin/sh to be run on the remote side, without a pseudo-tty. So, I'm not sure where tcsh even comes into play here. Maybe if you try changing the initialization command to: ssh -e none user@host exec /bin/sh Does that make a difference? -- 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
Re: [fossil-users] ssh transport and tcsh
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
Re: [fossil-users] ssh transport and tcsh
On Wed, Feb 6, 2013 at 3:12 PM, Matt Welland estifo...@gmail.com wrote:
On Wed, Feb 6, 2013 at 1:52 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Feb 6, 2013 at 3:39 PM, Matt Welland estifo...@gmail.com wrote:
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.comwrote:
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
The command:
ssh -e none user@host /bin/sh
should cause /bin/sh to be run on the remote side, without a pseudo-tty.
So, I'm not sure where tcsh even comes into play here. Maybe if you try
changing the initialization command to:
ssh -e none user@host exec /bin/sh
Does that make a difference?
Yes. The following patch appears to fix the problem:
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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
Re: [fossil-users] ssh transport and tcsh
On Wed, Feb 6, 2013 at 5:07 PM, Martin Gagnon eme...@gmail.com wrote: 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 With some experimentation, it seems that on my Linux Debian computer, this is not true, If I put a echo on top of my bashrc file, don't matter if I specify a command or not, I will see the echo. But on my OpenBSD box, I will see it only if I *don't* specify a command. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssh transport and tcsh
On Wed, Feb 6, 2013 at 5:45 PM, Martin Gagnon eme...@gmail.com wrote: With some experimentation, it seems that on my Linux Debian computer, this is not true, If I put a echo on top of my bashrc file, don't matter if I specify a command or not, I will see the echo. But on my OpenBSD box, I will see it only if I *don't* specify a command. On *my* Debian box, it works if I append /bin/bash, but fails if I append /bin/sh or /bin/tcsh. On my debian box, /bin/sh is a symlink to /bin/dash (which I have never heard of before). I have not yet figured out what is different in /bin/bash versus the others that is making the difference. -- 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
Re: [fossil-users] ssh transport and tcsh
I got some help from a co-worker to test this fix. He ran 1000's of clones
with bash as a login shell and with tcsh as a login shell with zero
problems. Can a couple other folks test it and can it then get into the
official release (assuming no problems found)?
It would be a real boon for me and some of my co-workers to have this
working :)
Cheers,
Matt
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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
Re: [fossil-users] ssh transport and tcsh
On Wed, Feb 6, 2013 at 6:22 PM, Matt Welland estifo...@gmail.com wrote:
I got some help from a co-worker to test this fix. He ran 1000's of clones
with bash as a login shell and with tcsh as a login shell with zero
problems. Can a couple other folks test it and can it then get into the
official release (assuming no problems found)?
It would be a real boon for me and some of my co-workers to have this
working :)
I want to understand the problem before I put in the fix.
To try to help better understand what is happening, I have added a new
query parameter to the ssh: url scheme. You can now say:
fossil clone ssh://user@host/path/to/repo?shell=/bin/bash new.fossil
and that will cause Fossil to add the /bin/bash argument to the end of
the ssh command. Please note that you can also do --sshtrace to get some
interactive information on what the ssh command is doing.
On my debian system, the clone hangs with shell=/bin/tcsh and with
shell=/bin/sh but works with shell=/bin/bash. Except if I also add the
--httptrace argument, then all three work. The --httptrace argument
disables compression of the content moving over the wire. So perhaps the
problem is that with compression turned on you occasionally get binary 0x00
bytes moving over the wire, which confuses /bin/tcsh and /bin/dash but not
/bin/bash. Just a guess.
Note that you have long had a query parameter
fossil=/path/to/fossil/on/remote/system with the ssh: scheme that lets you
specify a particular version of fossil to run on the remote system. At
least on my machine, my fossil binaries is not on the path set up by
.cshrc, so I also have to manually specify the location of the fossil
binary if I change from using /bin/bash.
Cheers,
Matt
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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
--
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
Re: [fossil-users] ssh transport and tcsh
On Wed, Feb 6, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Feb 6, 2013 at 6:22 PM, Matt Welland estifo...@gmail.com wrote:
I got some help from a co-worker to test this fix. He ran 1000's of clones
with bash as a login shell and with tcsh as a login shell with zero
problems. Can a couple other folks test it and can it then get into the
official release (assuming no problems found)?
It would be a real boon for me and some of my co-workers to have this
working :)
I want to understand the problem before I put in the fix.
To try to help better understand what is happening, I have added a new query
parameter to the ssh: url scheme. You can now say:
fossil clone ssh://user@host/path/to/repo?shell=/bin/bash new.fossil
and that will cause Fossil to add the /bin/bash argument to the end of the
ssh command. Please note that you can also do --sshtrace to get some
interactive information on what the ssh command is doing.
This idea seems good to me. I'll test it tomorrow. Thanks!
On my debian system, the clone hangs with shell=/bin/tcsh and with
shell=/bin/sh but works with shell=/bin/bash. Except if I also add the
--httptrace argument, then all three work. The --httptrace argument disables
compression of the content moving over the wire. So perhaps the problem is
that with compression turned on you occasionally get binary 0x00 bytes moving
over the wire, which confuses /bin/tcsh and /bin/dash but not /bin/bash.
Just a guess.
I did try stty raw thinking it might be xon/xoff or other
handshaking but got errors with the command.
Note that you have long had a query parameter
fossil=/path/to/fossil/on/remote/system with the ssh: scheme that lets you
specify a particular version of fossil to run on the remote system. At least
on my machine, my fossil binaries is not on the path set up by .cshrc, so I
also have to manually specify the location of the fossil binary if I change
from using /bin/bash.
Yep, I used the ?fossil= to do my testing. This approach with the
query parameters is very useful.
Cheers,
Matt
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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
--
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
