Feature freeze and Tramp?

Feature freeze and Tramp?

[Kai Grossjohann]

I'm not sure what I should do about Tramp given the feature freeze.  I
would like to merge 2.0.40 with Emacs, but it is not purely a bugfix
release: 2.0.39 contained half of the functionality needed for
password caching (it has the password cache), 2.0.40 supplies the
other half (it /uses/ the password cache).

There is now a stable branch in the Tramp repository so that it is
easier to make sure that future revisions in the 2.0 series are
bugfix-only.

What should I do?

tia,
Kai

Re: Feature freeze and Tramp?

[David Kastrup]

Kai Grossjohann <kai@emptydomain.de> writes:

> I'm not sure what I should do about Tramp given the feature freeze.  I
> would like to merge 2.0.40 with Emacs, but it is not purely a bugfix
> release: 2.0.39 contained half of the functionality needed for
> password caching (it has the password cache), 2.0.40 supplies the
> other half (it /uses/ the password cache).
> 
> There is now a stable branch in the Tramp repository so that it is
> easier to make sure that future revisions in the 2.0 series are
> bugfix-only.
> 
> What should I do?

In a stable release, there really is no place for half-implemented
stuff.  Either one should rewind to the state before the
half-implementation, backing it out modulo bug-fixes, or one should
complete it.  Considering the additional work of maintaining a
separate back-ported branch that would have to be created separately,
and considering the relative youth of the feature freeze and the
number of things that have just gotten in, I'd say in this case put it
in and maintain the stable branch from this point on.  Considering
your narrow focus, it is highly unlikely that problems with Tramp
2.0.40 will slow down the proper release in any manner.

The purpose of the feature freeze is to concentrate on getting work
done and finished, not on starting new work in the form of backports.
Unless this appears necessary for getting the release out.  I think
that the additional work of backports will mostly be warranteed close
to the finishing line.

Half-finished stuff should get finished or taken out.  Unless this
affects stability, I'd opt for putting it in in this case.  If it
turns out that this has been the wrong choice, we can still back it
out again.

The same holds for other stuff: if it turns out that we have no way to
get them stable in reasonable time, there will be a point of time when
we rather take them out than try to fix them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Feature freeze and Tramp?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: 02 May 2004 21:19:39 +0200
> 
> Considering the additional work of maintaining a separate
> back-ported branch that would have to be created separately, and
> considering the relative youth of the feature freeze and the number
> of things that have just gotten in, I'd say in this case put it in
> and maintain the stable branch from this point on.

I second that.

Re: Feature freeze and Tramp?

[Kim F. Storm]

Kai Grossjohann <kai@emptydomain.de> writes:

> I'm not sure what I should do about Tramp given the feature freeze.  I
> would like to merge 2.0.40 with Emacs, but it is not purely a bugfix
> release: 2.0.39 contained half of the functionality needed for
> password caching (it has the password cache), 2.0.40 supplies the
> other half (it /uses/ the password cache).
> 
> There is now a stable branch in the Tramp repository so that it is
> easier to make sure that future revisions in the 2.0 series are
> bugfix-only.
> 
> What should I do?

Install your changes.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Feature freeze and Tramp?

[Richard Stallman]

Please install the new version of Tramp.

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Thanks to everyone for sharing their opinion.  I've now tried to
update Tramp to 2.0.40.

Kai

Re: Feature freeze and Tramp?

[Miles Bader]

Kai Grossjohann <kai@emptydomain.de> writes:
> Thanks to everyone for sharing their opinion.  I've now tried to
> update Tramp to 2.0.40.

Hi Kai,

The arch tagline for `man/trampver.texi' got stomped on.

Looking at it, it looks like a generated file -- should it not be stored
in the archive at all?  Or is a `generated but not locally' file?
If that's the case I can use an explicit tag instead of a tagline.

Thanks,

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Miles Bader <miles@gnu.org> writes:

> Kai Grossjohann <kai@emptydomain.de> writes:
>> Thanks to everyone for sharing their opinion.  I've now tried to
>> update Tramp to 2.0.40.
>
> The arch tagline for `man/trampver.texi' got stomped on.

Argh.  I forgot, /again/.  Sorry.  I've now tried to resurrect the
line.

> Looking at it, it looks like a generated file -- should it not be stored
> in the archive at all?  Or is a `generated but not locally' file?
> If that's the case I can use an explicit tag instead of a tagline.

In the Tramp CVS repository, the Tramp version is an Autoconf macro.
The file texi/trampver.texi.in in that repository contains an @FOO@
string, and texi/trampver.texi is generated from it to contain the
version number.

Then the file texi/trampver.texi is transferred to the Emacs CVS
repository.

So if I understand you correctly, the `generated but not locally' part
is true.

I've now put the arch tagline in trampver.texi.in, was this the right
thing to do?

Thanks for your patience,
Kai

Re: Feature freeze and Tramp?

[Miles Bader]

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Feature freeze and Tramp?

[Miles Bader]

Kai Grossjohann <kai@emptydomain.de> writes:
> I've now put the arch tagline in trampver.texi.in, was this the right
> thing to do?

I think it's not the right thing in general[*], but there's probably no
reason to change it unless problems crop up.

[*] Since a tagline assigns a unique identity to a file, putting it
    directly in the .in file means that (1) if you ever put the real
    virgin tramp sources in arch, the .in file will end up with the same
    `identity' as the generated file (which is clearly wrong), and
    (2) two different generated files in the same tree will conflict
    (this is a very unlikely case of course, since people tend not to do
    that).

-Miles
-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: Feature freeze and Tramp?

[Luc Teirlinck]

I do _not_ believe this is new behavior connected to the update.
But why does tramp insert 215 lines into the .bash_history on the
remote machine?  (This is annoying.)

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I do _not_ believe this is new behavior connected to the update.
> But why does tramp insert 215 lines into the .bash_history on the
> remote machine?  (This is annoying.)

Yes, I agree.  Tramp tries to turn that off, but maybe it is not
working for some reason.

During initialization of the remote shell connection, Tramp sends the
following command to the remote end:

    HISTFILE=$HOME/.tramp_history; HISTSIZE=1

So, perhaps the above command is not the right command for your remote
shell, or perhaps the command is not executed properly by Tramp.

If you (setq tramp-debug-buffer t) then you can see in the *debug
tramp/foo* buffer whether or not Tramp sends the line to the remote
end.  Could you please check this?  Could you also check whether the
command needs to be changed for your case to have the desired effect?

Thanks,
Kai

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Kai Grossjohann wrote:
   
   If you (setq tramp-debug-buffer t) then you can see in the *debug
   tramp/foo* buffer whether or not Tramp sends the line to the remote
   end.  Could you please check this?

Tramp _does_ send that line.

   Could you also check whether the command needs to be changed for
   your case to have the desired effect?

My original report concerned a remote machine running Solaris2.8.
I now tried it on a remote machine running GNU/Linux and there tramp
only inserted the 3 lines:

unset correct
unset autocorrect
exec env 'ENV=' 'PS1=$ ' /bin/sh

in .bash_history, which is still somewhat of a nuisance, but less than
hundreds, as happens on Solaris2.8.  A ~/.tramp_history file gets
created on GNU/Linux, but not on Solaris2.8.

I checked that running:

HISTFILE=~/nosuchfile
echo aha

will work (that is, create ~/nosuchfile and use it) on GNU/Linux,
whether you use sh or bash.  On Solaris2.8 it works if you use bash,
but not if you use sh.  _Maybe_ this can be considered to actually be
a bug in the Solaris2.8 version of sh, but I am not sure about that.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> will work (that is, create ~/nosuchfile and use it) on GNU/Linux,
> whether you use sh or bash.  On Solaris2.8 it works if you use bash,
> but not if you use sh.  _Maybe_ this can be considered to actually be
> a bug in the Solaris2.8 version of sh, but I am not sure about that.

Your original message said that hundreds of lines were inserted into
~/.bash_history.  Hm.  Does this mean that *sh* did that, and not
*bash*?

I think I have to reread your messages again to find out what's
happening.

Kai

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Kai Grossjohann wrote:
   
   Your original message said that hundreds of lines were inserted into
   ~/.bash_history.  Hm.  Does this mean that *sh* did that, and not
   *bash*?

I did not study the TRAMP shell script in full detail, but from the
fact that exporting the variables fixes the problem, I would _guess_
that a bash subshell of the sh shell does it.  Anyway, unless there is
a reason _not_ to export the variables, the patch below seems to fix
the problem.  Well, there still are 3 lines that get inserted into the
history, but that definitely is less bad than hundreds.

===File ~/tramp-diff========================================
*** tramp.el	07 May 2004 18:33:46 -0500	1.43
--- tramp.el	10 May 2004 18:12:13 -0500	
***************
*** 5621,5629 ****
  				     "stty -onlcr"))))
    (erase-buffer)
    (tramp-message
!    9 "Waiting 30s for `HISTFILE=$HOME/.tramp_history; HISTSIZE=1'")
    (tramp-send-command-internal multi-method method user host
! 			       "HISTFILE=$HOME/.tramp_history; HISTSIZE=1")
    (erase-buffer)
    (tramp-message 9 "Waiting 30s for `set +o vi +o emacs'")
    (tramp-send-command-internal multi-method method user host
--- 5621,5629 ----
  				     "stty -onlcr"))))
    (erase-buffer)
    (tramp-message
!    9 "Waiting 30s for `export HISTFILE=$HOME/.tramp_history HISTSIZE=1; export HISTFILE; export HISTSIZE'")
    (tramp-send-command-internal multi-method method user host
! 			       "HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE")
    (erase-buffer)
    (tramp-message 9 "Waiting 30s for `set +o vi +o emacs'")
    (tramp-send-command-internal multi-method method user host
============================================================

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I did not study the TRAMP shell script in full detail, but from the
> fact that exporting the variables fixes the problem, I would _guess_
> that a bash subshell of the sh shell does it.

Cool!  Thanks for the fix, will incorporate this into Tramp shortly.

Kai

Re: Feature freeze and Tramp?

[Luc Teirlinck]

There was a small typo in my previous patch:

--- 5621,5629 ----
  				     "stty -onlcr"))))
    (erase-buffer)
    (tramp-message
!    9 "Waiting 30s for `export HISTFILE=$HOME/.tramp_history HISTSIZE=1; export HISTFILE; export HISTSIZE'")

That leading `export' in the `tramp-message' should not be there and
there should be a semicolon after .tramp-history.  These typos
occurred only in the message however, the actual command sent was
correct.

Corrected version:

===File ~/tramp-diff========================================
*** tramp.el	07 May 2004 18:33:46 -0500	1.43
--- tramp.el	11 May 2004 19:32:58 -0500	
***************
*** 5621,5629 ****
  				     "stty -onlcr"))))
    (erase-buffer)
    (tramp-message
!    9 "Waiting 30s for `HISTFILE=$HOME/.tramp_history; HISTSIZE=1'")
    (tramp-send-command-internal multi-method method user host
! 			       "HISTFILE=$HOME/.tramp_history; HISTSIZE=1")
    (erase-buffer)
    (tramp-message 9 "Waiting 30s for `set +o vi +o emacs'")
    (tramp-send-command-internal multi-method method user host
--- 5621,5629 ----
  				     "stty -onlcr"))))
    (erase-buffer)
    (tramp-message
!    9 "Waiting 30s for `HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE'")
    (tramp-send-command-internal multi-method method user host
! 			       "HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE")
    (erase-buffer)
    (tramp-message 9 "Waiting 30s for `set +o vi +o emacs'")
    (tramp-send-command-internal multi-method method user host
============================================================

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Kai Grossjohann wrote:

   Cool!  Thanks for the fix, will incorporate this into Tramp shortly.

That leaves us with the issue of those three remaining lines which are
still somewhat of a nuisance.  They can be completely gotten rid of by
setting tramp-initial-commands to

("unset HISTFILE" "unset correct" "unset autocorrect")

where the order is, of course, important.  In other words "unset
HISTFILE" is pushed onto the default value.

I have customized tramp-initial-commands to the above in my personal
customizations.  Can the "unset HISTFILE" ever give problems on a
remote host running an exotic shell and, if so, would the two other
"unset" commands, present in the current default, not give problems on
that same host anyway?  Is there a reason not add "unset HISTFILE" to
the front of the default value, or at least, suggest doing so in
tramp-initial-commands' docstring?

("HISTFILE=" "export HISTFILE" "unset correct" "unset autocorrect")

would, I believe, make the 

"HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE"

unnecessary, but I am afraid that some shells might not recognize "export".
However, was there any reason to use "HISTFILE=$HOME/.tramp_history;
HISTSIZE=1;" instead of simply using "HISTFILE= ; export HISTFILE" at the
same spot?

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kai Grossjohann wrote:
>
>    Cool!  Thanks for the fix, will incorporate this into Tramp shortly.
>
> That leaves us with the issue of those three remaining lines which are
> still somewhat of a nuisance.  They can be completely gotten rid of by
> setting tramp-initial-commands to
>
> ("unset HISTFILE" "unset correct" "unset autocorrect")
>
> where the order is, of course, important.  In other words "unset
> HISTFILE" is pushed onto the default value.

I have added this.  It should be harmless at worst, and useful in many
cases.

> ("HISTFILE=" "export HISTFILE" "unset correct" "unset autocorrect")
>
> would, I believe, make the 
>
> "HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE"
>
> unnecessary, but I am afraid that some shells might not recognize "export".
> However, was there any reason to use "HISTFILE=$HOME/.tramp_history;
> HISTSIZE=1;" instead of simply using "HISTFILE= ; export HISTFILE" at the
> same spot?

The initial commands are sent to the login shell, which might be a
csh, and a csh doesn't grok export.  Therefore, putting export into
the initial commands doesn't seem to be right.

Bash isn't the only shell grokking HISTFILE and/or HISTSIZE; I think
the above construction was made to work with bash and ksh.  I'd have
to dig it up in the Tramp mailing list archives to find out which
shells have been tested.

In general, it is difficult to keep track of which shell is active at
any one moment, and which commands might cause problems.  For
instance, I used to have "unset foo >/dev/null; blah", only to find
out that some shells fail to execute blah if output from the builtin
is redirected...  

Regarding HISTFILE/HISTSIZE, I could find the following ChangeLog
entry:

2001-01-10  Kai Großjohann  <Kai.Grossjohann@CS.Uni-Dortmund.DE>

	* tramp.el (tramp-open-connection-setup-interactive-shell): `unset
	HISTFILE' rather than `set -o history' to turn off the history.
	Pete Forman says this works on bash1 and bash2, but not for ksh or
	a Posix sh.  He also says there's no way to turn history off for
	ksh and Posix shells, except by invoking non-interactively.  I
	won't do that, though, because I need the prompts.

HISTSIZE isn't mentioned at all, though.  Hm.  Ah, another entry:

2001-04-13  Kai Großjohann  <Kai.Grossjohann@CS.Uni-Dortmund.DE>

	* tramp.el (tramp-open-connection-setup-interactive-shell): Posix
	shells don't allow you to turn off the history, so we redirect it
	to an innocuous file and limits that file's size as much as
	possible.
	(tramp-find-executable): Be extra careful when searching for
	executables, include sentinel string to search for.

Does this help?

Kai

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Kai Grossjohann wrote:
	   
	   * tramp.el (tramp-open-connection-setup-interactive-shell): `unset
	   HISTFILE' rather than `set -o history' to turn off the history.

Is `set -o history' a typo?  In my version of bash that turns _on_
history and I have to use `set +o history' to turn it off.  Anyway,
this feature indeed seems to be bash-specific and hence useless if
you do not know that the shell is bash.

`unset HISTFILE' would not work at the particular spot anyway, even if
the shell is bash, because one has to export the "history-disabledness"
and "unsettedness" of variables does not get exported.

	   * tramp.el (tramp-open-connection-setup-interactive-shell): Posix
	   shells don't allow you to turn off the history, so we redirect it
	   to an innocuous file and limits that file's size as much as
	   possible.

They certainly do not allow `set +o history'.  After `bash --posix',
both `unset HISTFILE' and `HISTFILE=' seem to work.  But the fact that
they work in `bash --posix' is definitely no "proof".  Maybe some
other shells insist on using their default history file if HISTFILE is
either unset _or_ null, so it probably is safer to keep the current
constructs.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kai Grossjohann wrote:
> 	   
> 	   * tramp.el (tramp-open-connection-setup-interactive-shell): `unset
> 	   HISTFILE' rather than `set -o history' to turn off the history.
>
> Is `set -o history' a typo?

Perhaps it's a typo in the ChangeLog only.

> `unset HISTFILE' would not work at the particular spot anyway, even if
> the shell is bash, because one has to export the "history-disabledness"
> and "unsettedness" of variables does not get exported.

Really?  Below, you say that `unset HISTFILE' works...  Note that the
spot we're talking about here is in the correct shell already.

> 	   * tramp.el (tramp-open-connection-setup-interactive-shell): Posix
> 	   shells don't allow you to turn off the history, so we redirect it
> 	   to an innocuous file and limits that file's size as much as
> 	   possible.
>
> They certainly do not allow `set +o history'.  After `bash --posix',
> both `unset HISTFILE' and `HISTFILE=' seem to work.  But the fact that
> they work in `bash --posix' is definitely no "proof".  Maybe some
> other shells insist on using their default history file if HISTFILE is
> either unset _or_ null, so it probably is safer to keep the current
> constructs.

Experience tells me that /bin/sh and ksh should be tested on AIX and
IRIX, at least, to make sure it's okay.  Perhaps a BSD should also be
tested.

It is of course cleaner to have no history at all ;-)  So I think I
would change if it works on SunOS, Solaris, AIX, IRIX, and one of the
BSDs.  (sh and ksh need to be tested on those OSes.)

Kai

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Kai Grossjohann wrote:
   
   Really?  Below, you say that `unset HISTFILE' works...  Note that the
   spot we're talking about here is in the correct shell already.

Remember that one apparently has to _export_ HISTFILE at that spot.

`unset HISTFILE' works in the shell in which you execute it, but if
you start a subshell, the subshell will re-initialize HISTFILE to its
default value.  If you do `HISTFILE= ; export HISTFILE', the subshell
will not re-initialize HISTFILE, which will remain null.  At least all of
this is the case for bash, including when invoked as sh or `bash --posix'.
Solaris2.8' sh does not seem to keep history at all.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kai Grossjohann wrote:
>    
>    Really?  Below, you say that `unset HISTFILE' works...  Note that the
>    spot we're talking about here is in the correct shell already.
>
> Remember that one apparently has to _export_ HISTFILE at that spot.
>
> `unset HISTFILE' works in the shell in which you execute it, but if
> you start a subshell, the subshell will re-initialize HISTFILE to its
> default value.  If you do `HISTFILE= ; export HISTFILE', the subshell
> will not re-initialize HISTFILE, which will remain null.  At least all of
> this is the case for bash, including when invoked as sh or `bash --posix'.
> Solaris2.8' sh does not seem to keep history at all.

The function tramp-open-connection-setup-interactive-shell is run
after the correct shell has been entered on the remote end, whereas
tramp-actions-before-shell is executed earlier, before the "right"
shell has been started.

Therefore, "unset HISTFILE" may fail from tramp-actions-before-shell,
but I expect it to succeed from
tramp-open-connection-setup-interactive-shell.

Of course, I think that you observed it to fail from
tramp-open-connection-setup-interactive-shell, so I must be missing
something somewhere :-|

Kai

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Kai Grossjohann wrote:

   Of course, I think that you observed it to fail from
   tramp-open-connection-setup-interactive-shell, so I must be missing
   something somewhere :-|

Only on Solaris actually (Solaris2.8, more precisely).  Strangely,
exporting does _not_ seem necessary on GNU/Linux.  So _maybe_ Solaris' sh
uses a subshell for something bash uses no subshell for.  I just
observed facts empirically.   I do not understand them.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Only on Solaris actually (Solaris2.8, more precisely).  Strangely,
> exporting does _not_ seem necessary on GNU/Linux.  So _maybe_ Solaris' sh
> uses a subshell for something bash uses no subshell for.  I just
> observed facts empirically.   I do not understand them.

Please submit a Tramp bug report, including the *debug tramp/foo*
buffer as described in the instructions you get after M-x tramp-bug
RET.  Maybe that enables me to see what is going on.

Thanks,
Kai

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Kai Grossjohann wrote:

   Please submit a Tramp bug report, including the *debug tramp/foo*
   buffer as described in the instructions you get after M-x tramp-bug
   RET.  Maybe that enables me to see what is going on.

I could submit a bug report if really necessary.  However, I now
looked somewhat closer at the Tramp code and now the reason why you
need to export on Solaris and not on GNU/Linux seems obvious.
Solaris' sh can not handle ~, sh on GNU/Linux, that is, bash run as sh,
can handle ~.  Tramp still runs tramp-post-connection _after_ running
tramp-open-connection-setup-interactive-shell.

The result of all of this is that on Solaris you get (excerpts of the
Tramp debug buffer with my own comments):
...
teirllm@raven$ $ exec env 'ENV=' 'PS1=$ ' /bin/sh
# Waiting 30s for remote `/bin/sh' to come up...
...
$ # Waiting 30s for `HISTFILE= ; export HISTFILE'
$ HISTFILE= ; export HISTFILE
(But the `export' is just something I put in my private Tramp.  The above
works on Solaris and on GNU/Linux.  I can not check on other operating
systems.)
...
tramp_executable /bin/bash
# Starting remote shell `/bin/bash -norc -noprofile' for tilde
expansion...
(This is why you _need_ the `export'.  Otherwise this shell writes to
.bashhistory.  Hundreds of lines.)

On the other hand, on GNU/Linux we get instead:

# Remote `/bin/sh' groks tilde expansion, good

Hence, no `export' needed on GNU/Linux.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I could submit a bug report if really necessary.  However, I now
> looked somewhat closer at the Tramp code and now the reason why you
> need to export on Solaris and not on GNU/Linux seems obvious.
> Solaris' sh can not handle ~, sh on GNU/Linux, that is, bash run as sh,
> can handle ~.  Tramp still runs tramp-post-connection _after_ running
> tramp-open-connection-setup-interactive-shell.

D'oh!  And I thought that
tramp-open-connection-setup-interactive-shell was the last thing that
runs!

Hm.  I could run tramp-open-connection-setup-interactive-shell again
after starting the shell for tilde expansion.  Or perhaps I search
for a shell that groks tilde somewhat earlier.  Hm.

Thanks for finding out!

Kai

Re: Feature freeze and Tramp?

[Luc Teirlinck]

>From my previous message:

   I do _not_ believe this is new behavior connected to the update.
   But why does tramp insert 215 lines into the .bash_history on the
   remote machine?  (This is annoying.)

I forgot to say that this happens after visiting a file using the
/ssh:USER@HOST:FILENAME syntax.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Luc Teirlinck]

I do not know whether the following problem is connected to the update
or not.

Visit a file using the /ssh:USER@HOST:FILENAME syntax.  When the file
is displayed, close your connection.  Obviously, now tramp is not
going to be able to function normally anymore.  But what happens is
that Emacs now appears to freeze.  It does not even respond to C-g
anymore, and I had to kill it from the command line.  Is this really
unavoidable?  Closing one's connection forgetting that one has active
trap buffers _is_ sometimes going to happen, so the behavior is a
nuisance.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Robert J. Chassell]

   Visit a file using the /ssh:USER@HOST:FILENAME syntax.  When the file
   is displayed, close your connection.  Obviously, now tramp is not
   going to be able to function normally anymore.  But what happens is
   that Emacs now appears to freeze.  

I cannot repeat this using 
Today's CVS snapshot, Sun, 2004 May  9  12:17 UTC
GNU Emacs 21.3.50.23 (i686-pc-linux-gnu, GTK+ Version 2.2.4)
from which I am sending this message.

I just visited a remote file on a system *not* running GNU/Linux.  
`uname -a' says it is running 
    SunOS  5.9 Generic_112233-01 sun4u sparc SUNW,Ultra-2

After visiting the remote file, by evaluating the following

    (find-file 
     "/ssh:bob@shell.berkshire.net:/home/bob/www/notions/notions.html" 
     nil)

I killed my dial up connection, and reconnected (with lots of trouble,
because my local phone line has gone bad again).  I am able to make
changes to the remote file and save them.  Other tha being much slower
than ange-ftp, Tramp with SSH seems to work fine.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Robert Chassell wrote:

      Visit a file using the /ssh:USER@HOST:FILENAME syntax.  When the file
      is displayed, close your connection.  Obviously, now tramp is not
      going to be able to function normally anymore.  But what happens is
      that Emacs now appears to freeze.  

   I cannot repeat this using 
   Today's CVS snapshot, Sun, 2004 May  9  12:17 UTC
   GNU Emacs 21.3.50.23 (i686-pc-linux-gnu, GTK+ Version 2.2.4)
   from which I am sending this message.

I sdomehow forgot to double check this using emacs -q.  (Sorry, I
should have known better.)

auto-revert-mode causes the freeze.  This looks like a bug in
auto-revert-mode.  I will take a look at it and see whether I can fix
it.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Stefan Monnier]

> auto-revert-mode causes the freeze.  This looks like a bug in
> auto-revert-mode.  I will take a look at it and see whether I can fix it.

The problem is likely to be that inhibit-quit is bound to non-nil while
running timers (such as the auto-revert timer).  So you might want to
wrap the auto-revert timer code with `with-local-quit'.

But it would probably be better to use with-local-quit at the place where
it's actually needed: around any potentially indefinitely blocking piece
of code.  In this case it would be within Tramp around one of its calls
to accept-process-output (or around one of the loops that calls
accept-process-output).


        Stefan

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Stefan Monnier wrote:

   > auto-revert-mode causes the freeze.  This looks like a bug in
   > auto-revert-mode.  I will take a look at it and see whether I can fix it.

   The problem is likely to be that inhibit-quit is bound to non-nil while
   running timers (such as the auto-revert timer).  So you might want to
   wrap the auto-revert timer code with `with-local-quit'.

   But it would probably be better to use with-local-quit at the place where
   it's actually needed: around any potentially indefinitely blocking piece
   of code.  In this case it would be within Tramp around one of its calls
   to accept-process-output (or around one of the loops that calls
   accept-process-output).

I wrapped all relevant code with `with-local-quit'.  Now it is indeed
possible to quit, but the problem restarts 0 to auto-revert-interval
seconds later (as expected), unless one manages to kill all involved
buffers, or to disable Global Auto Revert Mode, in the meantime.

The trivial patch below completely solves the problem, but at the
expense of disabling the auto-reverting of remote files altogether.

The problem is that currently the Tramp handling of `file-exists-p'
and friends is very expensive if one has a slow connection, and
prohibitively expensive when not connected.  Indeed, then each single
call to `file-exists-p' and friends will take at least one full minute.

===File ~/autorevert-diff-1=================================
*** autorevert.el	04 Apr 2004 19:50:59 -0500	1.29
--- autorevert.el	09 May 2004 13:57:03 -0500	
***************
*** 311,316 ****
--- 311,317 ----
    (unless (buffer-modified-p)
      (let ((buffer (current-buffer)) revert eob eoblist)
        (or (and buffer-file-name
+ 	       (not (file-remote-p buffer-file-name))
  	       (file-readable-p buffer-file-name)
  	       (not (verify-visited-file-modtime buffer))
  	       (setq revert t))
============================================================

Re: Feature freeze and Tramp?

[Luc Teirlinck]

Once more, insert a file using the /ssh:USER@HOST:FILENAME syntax.
Do this often for the same file, say:

/ssh:teirllm@mymachine.dms.auburn.edu:~/270moves

Most of the type things work right, but somehow, unpredictably, one
sometimes gets the error message:

vc-rcs-fetch-master-state: File
/ssh:teirllm@mymachine.dms.auburn.edu:/home/teirllm/RCS/270moves is not an
RCS master file

Strange.

Sincerely,

Luc.

Re: Feature freeze and Tramp?

[Luc Teirlinck]

>From my earlier message:
   
   Once more, insert a file using the /ssh:USER@HOST:FILENAME syntax.
   
I meant _visit_ a file (C-x C-f) 
   
   Do this often for the same file, say:

   /ssh:teirllm@mymachine.dms.auburn.edu:~/270moves

   Most of the type things work right, but somehow, unpredictably, one
   sometimes gets the error message:

   vc-rcs-fetch-master-state: File
   /ssh:teirllm@mymachine.dms.auburn.edu:/home/teirllm/RCS/270moves is not an
   RCS master file

I forgot to say that both local and remote machine use GNU/Linux.

Sincerely,

Luc.