* Feature freeze and Tramp? @ 2004-05-02 18:43 Kai Grossjohann 2004-05-02 19:19 ` David Kastrup ` (3 more replies) 0 siblings, 4 replies; 35+ messages in thread From: Kai Grossjohann @ 2004-05-02 18:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-02 18:43 Feature freeze and Tramp? Kai Grossjohann @ 2004-05-02 19:19 ` David Kastrup 2004-05-03 6:20 ` Eli Zaretskii 2004-05-03 6:03 ` Kim F. Storm ` (2 subsequent siblings) 3 siblings, 1 reply; 35+ messages in thread From: David Kastrup @ 2004-05-02 19:19 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-02 19:19 ` David Kastrup @ 2004-05-03 6:20 ` Eli Zaretskii 0 siblings, 0 replies; 35+ messages in thread From: Eli Zaretskii @ 2004-05-03 6:20 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-02 18:43 Feature freeze and Tramp? Kai Grossjohann 2004-05-02 19:19 ` David Kastrup @ 2004-05-03 6:03 ` Kim F. Storm 2004-05-03 14:03 ` Richard Stallman 2004-05-07 21:23 ` Kai Grossjohann 3 siblings, 0 replies; 35+ messages in thread From: Kim F. Storm @ 2004-05-03 6:03 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-02 18:43 Feature freeze and Tramp? Kai Grossjohann 2004-05-02 19:19 ` David Kastrup 2004-05-03 6:03 ` Kim F. Storm @ 2004-05-03 14:03 ` Richard Stallman 2004-05-07 21:23 ` Kai Grossjohann 3 siblings, 0 replies; 35+ messages in thread From: Richard Stallman @ 2004-05-03 14:03 UTC (permalink / raw) Cc: emacs-devel Please install the new version of Tramp. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-02 18:43 Feature freeze and Tramp? Kai Grossjohann ` (2 preceding siblings ...) 2004-05-03 14:03 ` Richard Stallman @ 2004-05-07 21:23 ` Kai Grossjohann 2004-05-07 22:22 ` Miles Bader ` (4 more replies) 3 siblings, 5 replies; 35+ messages in thread From: Kai Grossjohann @ 2004-05-07 21:23 UTC (permalink / raw) Thanks to everyone for sharing their opinion. I've now tried to update Tramp to 2.0.40. Kai ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-07 21:23 ` Kai Grossjohann @ 2004-05-07 22:22 ` Miles Bader 2004-05-08 10:15 ` Kai Grossjohann 2004-05-08 2:34 ` Luc Teirlinck ` (3 subsequent siblings) 4 siblings, 1 reply; 35+ messages in thread From: Miles Bader @ 2004-05-07 22:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-07 22:22 ` Miles Bader @ 2004-05-08 10:15 ` Kai Grossjohann 2004-05-10 1:33 ` Miles Bader 2004-05-10 1:39 ` Miles Bader 0 siblings, 2 replies; 35+ messages in thread From: Kai Grossjohann @ 2004-05-08 10:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-08 10:15 ` Kai Grossjohann @ 2004-05-10 1:33 ` Miles Bader 2004-05-10 1:39 ` Miles Bader 1 sibling, 0 replies; 35+ messages in thread From: Miles Bader @ 2004-05-10 1:33 UTC (permalink / raw) Cc: emacs-devel -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-08 10:15 ` Kai Grossjohann 2004-05-10 1:33 ` Miles Bader @ 2004-05-10 1:39 ` Miles Bader 1 sibling, 0 replies; 35+ messages in thread From: Miles Bader @ 2004-05-10 1:39 UTC (permalink / raw) Cc: emacs-devel 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))) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-07 21:23 ` Kai Grossjohann 2004-05-07 22:22 ` Miles Bader @ 2004-05-08 2:34 ` Luc Teirlinck 2004-05-08 10:34 ` Kai Grossjohann 2004-05-08 3:15 ` Luc Teirlinck ` (2 subsequent siblings) 4 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-08 2:34 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-08 2:34 ` Luc Teirlinck @ 2004-05-08 10:34 ` Kai Grossjohann 2004-05-09 1:40 ` Luc Teirlinck 0 siblings, 1 reply; 35+ messages in thread From: Kai Grossjohann @ 2004-05-08 10:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-08 10:34 ` Kai Grossjohann @ 2004-05-09 1:40 ` Luc Teirlinck 2004-05-10 13:02 ` Kai Grossjohann 0 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-09 1:40 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-09 1:40 ` Luc Teirlinck @ 2004-05-10 13:02 ` Kai Grossjohann 2004-05-11 2:49 ` Luc Teirlinck 0 siblings, 1 reply; 35+ messages in thread From: Kai Grossjohann @ 2004-05-10 13:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-10 13:02 ` Kai Grossjohann @ 2004-05-11 2:49 ` Luc Teirlinck 2004-05-11 7:08 ` Kai Grossjohann 0 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-11 2:49 UTC (permalink / raw) Cc: emacs-devel 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 ============================================================ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-11 2:49 ` Luc Teirlinck @ 2004-05-11 7:08 ` Kai Grossjohann 2004-05-12 0:53 ` Luc Teirlinck 2004-05-12 1:02 ` Luc Teirlinck 0 siblings, 2 replies; 35+ messages in thread From: Kai Grossjohann @ 2004-05-11 7:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-11 7:08 ` Kai Grossjohann @ 2004-05-12 0:53 ` Luc Teirlinck 2004-05-12 1:02 ` Luc Teirlinck 1 sibling, 0 replies; 35+ messages in thread From: Luc Teirlinck @ 2004-05-12 0:53 UTC (permalink / raw) Cc: emacs-devel 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 ============================================================ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-11 7:08 ` Kai Grossjohann 2004-05-12 0:53 ` Luc Teirlinck @ 2004-05-12 1:02 ` Luc Teirlinck 2004-05-12 7:32 ` Kai Grossjohann 1 sibling, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-12 1:02 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-12 1:02 ` Luc Teirlinck @ 2004-05-12 7:32 ` Kai Grossjohann 2004-05-12 14:57 ` Luc Teirlinck 0 siblings, 1 reply; 35+ messages in thread From: Kai Grossjohann @ 2004-05-12 7:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-12 7:32 ` Kai Grossjohann @ 2004-05-12 14:57 ` Luc Teirlinck 2004-05-13 6:54 ` Kai Grossjohann 0 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-12 14:57 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-12 14:57 ` Luc Teirlinck @ 2004-05-13 6:54 ` Kai Grossjohann 2004-05-13 14:02 ` Luc Teirlinck 0 siblings, 1 reply; 35+ messages in thread From: Kai Grossjohann @ 2004-05-13 6:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-13 6:54 ` Kai Grossjohann @ 2004-05-13 14:02 ` Luc Teirlinck 2004-05-15 16:36 ` Kai Grossjohann 0 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-13 14:02 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-13 14:02 ` Luc Teirlinck @ 2004-05-15 16:36 ` Kai Grossjohann 2004-05-15 18:28 ` Luc Teirlinck 0 siblings, 1 reply; 35+ messages in thread From: Kai Grossjohann @ 2004-05-15 16:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-15 16:36 ` Kai Grossjohann @ 2004-05-15 18:28 ` Luc Teirlinck 2004-05-16 9:07 ` Kai Grossjohann 0 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-15 18:28 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-15 18:28 ` Luc Teirlinck @ 2004-05-16 9:07 ` Kai Grossjohann 2004-05-17 0:50 ` Luc Teirlinck 0 siblings, 1 reply; 35+ messages in thread From: Kai Grossjohann @ 2004-05-16 9:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-16 9:07 ` Kai Grossjohann @ 2004-05-17 0:50 ` Luc Teirlinck 2004-05-17 5:11 ` Kai Grossjohann 0 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-17 0:50 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-17 0:50 ` Luc Teirlinck @ 2004-05-17 5:11 ` Kai Grossjohann 0 siblings, 0 replies; 35+ messages in thread From: Kai Grossjohann @ 2004-05-17 5:11 UTC (permalink / raw) Cc: kai.grossjohann, emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-07 21:23 ` Kai Grossjohann 2004-05-07 22:22 ` Miles Bader 2004-05-08 2:34 ` Luc Teirlinck @ 2004-05-08 3:15 ` Luc Teirlinck 2004-05-09 2:11 ` Luc Teirlinck 2004-05-09 2:34 ` Luc Teirlinck 4 siblings, 0 replies; 35+ messages in thread From: Luc Teirlinck @ 2004-05-08 3:15 UTC (permalink / raw) Cc: emacs-devel >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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-07 21:23 ` Kai Grossjohann ` (2 preceding siblings ...) 2004-05-08 3:15 ` Luc Teirlinck @ 2004-05-09 2:11 ` Luc Teirlinck 2004-05-09 15:35 ` Robert J. Chassell 2004-05-09 2:34 ` Luc Teirlinck 4 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-09 2:11 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-09 2:11 ` Luc Teirlinck @ 2004-05-09 15:35 ` Robert J. Chassell 2004-05-09 16:26 ` Luc Teirlinck 0 siblings, 1 reply; 35+ messages in thread From: Robert J. Chassell @ 2004-05-09 15:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-09 15:35 ` Robert J. Chassell @ 2004-05-09 16:26 ` Luc Teirlinck 2004-05-09 20:11 ` Stefan Monnier 0 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-09 16:26 UTC (permalink / raw) Cc: kai, emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-09 16:26 ` Luc Teirlinck @ 2004-05-09 20:11 ` Stefan Monnier 2004-05-10 0:08 ` Luc Teirlinck 0 siblings, 1 reply; 35+ messages in thread From: Stefan Monnier @ 2004-05-09 20:11 UTC (permalink / raw) Cc: bob, kai, emacs-devel > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-09 20:11 ` Stefan Monnier @ 2004-05-10 0:08 ` Luc Teirlinck 0 siblings, 0 replies; 35+ messages in thread From: Luc Teirlinck @ 2004-05-10 0:08 UTC (permalink / raw) Cc: bob, kai, emacs-devel 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)) ============================================================ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-07 21:23 ` Kai Grossjohann ` (3 preceding siblings ...) 2004-05-09 2:11 ` Luc Teirlinck @ 2004-05-09 2:34 ` Luc Teirlinck 2004-05-09 2:53 ` Luc Teirlinck 4 siblings, 1 reply; 35+ messages in thread From: Luc Teirlinck @ 2004-05-09 2:34 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Feature freeze and Tramp? 2004-05-09 2:34 ` Luc Teirlinck @ 2004-05-09 2:53 ` Luc Teirlinck 0 siblings, 0 replies; 35+ messages in thread From: Luc Teirlinck @ 2004-05-09 2:53 UTC (permalink / raw) Cc: kai, emacs-devel >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. ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2004-05-17 5:11 UTC | newest] Thread overview: 35+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-05-02 18:43 Feature freeze and Tramp? Kai Grossjohann 2004-05-02 19:19 ` David Kastrup 2004-05-03 6:20 ` Eli Zaretskii 2004-05-03 6:03 ` Kim F. Storm 2004-05-03 14:03 ` Richard Stallman 2004-05-07 21:23 ` Kai Grossjohann 2004-05-07 22:22 ` Miles Bader 2004-05-08 10:15 ` Kai Grossjohann 2004-05-10 1:33 ` Miles Bader 2004-05-10 1:39 ` Miles Bader 2004-05-08 2:34 ` Luc Teirlinck 2004-05-08 10:34 ` Kai Grossjohann 2004-05-09 1:40 ` Luc Teirlinck 2004-05-10 13:02 ` Kai Grossjohann 2004-05-11 2:49 ` Luc Teirlinck 2004-05-11 7:08 ` Kai Grossjohann 2004-05-12 0:53 ` Luc Teirlinck 2004-05-12 1:02 ` Luc Teirlinck 2004-05-12 7:32 ` Kai Grossjohann 2004-05-12 14:57 ` Luc Teirlinck 2004-05-13 6:54 ` Kai Grossjohann 2004-05-13 14:02 ` Luc Teirlinck 2004-05-15 16:36 ` Kai Grossjohann 2004-05-15 18:28 ` Luc Teirlinck 2004-05-16 9:07 ` Kai Grossjohann 2004-05-17 0:50 ` Luc Teirlinck 2004-05-17 5:11 ` Kai Grossjohann 2004-05-08 3:15 ` Luc Teirlinck 2004-05-09 2:11 ` Luc Teirlinck 2004-05-09 15:35 ` Robert J. Chassell 2004-05-09 16:26 ` Luc Teirlinck 2004-05-09 20:11 ` Stefan Monnier 2004-05-10 0:08 ` Luc Teirlinck 2004-05-09 2:34 ` Luc Teirlinck 2004-05-09 2:53 ` Luc Teirlinck
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).