thanks for responding.
On Sat, 10 Nov 2012 17:53:40 +0100, Martin Gagnon <eme...@gmail.com> wrote:
On Sat, Nov 10, 2012 at 9:48 AM, Richard Hipp <d...@sqlite.org> wrote:
On Sat, Nov 10, 2012 at 9:43 AM, j. van den hoff
<veedeeh...@googlemail.com>
wrote:
I would really appreciate if the ssh issue could get addressed by the
developers.
It has my attention. I just don't know what to do about it. Do you
have
any suggestions on how to improve the way the SSH method operates?
I think someone have proposed the ideal solution previously in this
list (I didn't find it on the mailing list archive, yet)
It would be to execute directly fossil throught ssh with a new fossil
command which would act similar as "fossil test-http", except that it
would process all chunks of sync data until the whole sync/push/pull
is completed.
That way fossil on local side would be directly connected to the
remote fossil pipe and nothing from shell or login session could be in
the way.
Let say the new fossil command is: fossil ssh-http
So instead of invoking: "ssh -T -e none remotehost", fossil would do:
"fossil remotehost fossil ssh-http"
When specifying a command to the ssh command line, stdin and stdout
are directly connected to the invoked command, so you cannot have
gargabe between.
I beleive it's how other scm use ssh...
thanks for clarifying. I did some further testing and finally managed to
make my setup compliant with fossil's demands.
I consider to be the following describing the state of affairs (valid for
a recent +bash+ on recent ubuntu -- with +tcsh+ it seems not to work
anyway):
* fossil does indeed an interactive ssh login. that implies
- the user's +.profile+ is processed (in agreement with the +bash+ manpage)
- the user's +.bashrc+ is _not_ processed (seemingly in _disagreement --
if I read it correctly -- with the +bash+ manpage)
* after +.profile+ is processed, +fossil+ needs to be on the search path.
setting the path in +.bashrc+ is too late
* _any_ tty ouput during the login procedure must be strictly prevented
either from the system (MOTD) or from +.profile+
- at least on ubuntu the former (system message) can be prevented by doing
+touch .hushlogin+ in the user's home directory.
- the former (tty output from +.profile+) can occur in unexpected (for me
at least) ways, even unprintable characters can
do harm: for instance, in my interactive
setup I put the name of the working directory in the title bar of the
terminal automatically after each cd by using
the corresponding xterm escape sequences. this is done, too, in .profile
in order to immediately have the correct title bar.
the catch is: these escape sequences are send to stdout just like text and
so they prevent fossil from working correctly.
but funny enough, this is only the case for +bash+: with +ksh+ sending
these escape sequences does no harm (while echoing
a single blank still does). my conclusion is: it is rather unfortunate that
+fossil+ relies on a "bare bones" interactive set up of the user's
account. minor fiddling with the setup can break everything.
I would say the bottom line from the above obviously is that using
interactive login is really fragile: (and I believe that's what you were
saying in the first place, right?). if it's true that the other scm avoid
this problem by avoiding interference of the shell, than that sure is
better in my view (as already stated: despite the "fancy" escape sequences
produced in my login scripts, +svn+ and +hg+ don't care at all and just
work -- with tcsh, too).
I'm nevertheless happy that I can report the problem to be solved for me:
in the end using +ksh+ as login shell on the remote machine for now seems
the best solution for me (since with bash fossil still chokes on the
mentioned escape sequences).
what I would think to be a good idea (as long as no "real" solution is in
place): to put a clear "howto make syncing over ssh work" on the fossil
webpage clearly stating that the login has to be _absolutely_ silent and
that (seemingly) only bash and ksh (zsh, too?) work, but tcsh doesn't.
might save new users
like me a lot of time in the future and provide on average better initial
experience with +fossil+ ;-).
good luck
joerg
--
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
