Re: Possible bug in TRAMP?

On 20 Mar 2005, at 18:18, Adrian Aichner wrote: > Another hint: > > Get rid of any tramp buffers staying around from previous sessions, > while debugging. Hi Adrian. Yes, I've been doing this. In fact, having stale tramp buffers around often stops it working at all. > Use > (setq tramp-debug-buffer t) > and see if that reveals any problems in buffers named > *debug tramp/sshx ... > *tramp/sshx ... > or similar. > > For the ssh methods I had to specify two -t switches to avoid a > pseudo-terminal not allocated warning. Did you do this on OS X? When I was using GNU Emacs on Jaguar, there

was a bug in the operating system which had to be worked around by setting process-connection-type to nil (as opposed to its default value of t). But Apple fixed this in the Panther release, so this workaround was no longer necessary. Are you referring to this?

Anyway, using sshx doesn't help. >> C-x C-f /[machine.name]:~/ TAB TAB > > You're not using that : in the line above, right? > > That would not be proper syntax. Ah, of course not :-) The colon there was just a typo. I should've used something like cut & paste, or something, instead.

> Ah, you should load the .el file instead of the .elc file for a better > *Backtrace*. > > Don't know which file it would be in this case, but you could load all > tramp*.el files for debugging. OK, I did this by renaming all the *.elc files in the tramp package to give them a "disable" suffix, and then restarting XEmacs. For my own future reference, is there a better way than this?

Debugger entered--Lisp error: (invalid-state "Bogus value for `default-process-coding-system'" nil) signal(invalid-state ("Bogus value for `default-process-coding-system'" nil)) byte-code("..." [buf data kill-buffer signal] 3) find-file-noselect("/[ssh/127.0.0.1]/Users/andrew/README") mapcar(find-file-noselect ("/[ssh/127.0.0.1]/Users/andrew/README")) find-file-noselect("/[127.0.0.1]~/README" nil nil t) #<compiled-function (filename &optional codesys wildcards) "...(53)" [coding-system-for-read wildcards filename codesys value get-coding-system find-file-noselect nil mapcar switch-to-buffer] 6 1033199 (list (read-file-name "Find file: ") (and current-prefix-arg ...) t)>("/[127.0.0.1]~/README" nil t) call-interactively(find-file) N.B. I've changed my test case, but it the results are essentially the same. I've found that disabling the remote uuencode and uudecode command line tools makes the problem go away. Of course this is not the correct solution. In this case, the tramp debug buffer shows that their nonexistence is detected, tramp uses its own encoding/decoding commands, and then decoding of the requested file is done locally with base64-decode-region and it's OK.

In the buggy case, the tramp debug buffer shows # Decoding remote file /[ssh/127.0.0.1]/Users/andrew/README with function uudecode-decode-region... at which point the debugger comes on and I see the backtrace. Is this helpful?

Andrew