I'm trying, for the first time, to access remote files via tramp from Emacs on Windows. I'm trying to open a remote directory via C-x C-f /plink:user#host:/. However, when Emacs gets to "Tramp: found remote shell prompt" in the minibuffer, it hangs. And not only does the minibuffer hang, but all of Emacs hangs, so that I have to kill it via task manager. This unfortunately means that I can't see any debug information for tramp, because it outputs to an Emacs buffer. How can I go about debugging this?
I'm running Windows 8.1, Emacs 24.3, and plink 0.63.
I ran into a very similar situation with tramp ssh, and I can't guess at what your particular problem is, but only that you can get a complete trace by doing:
(setq tramp-verbose 10)
Then try the connection again, and after it hangs, C-g and check for a buffer:
*debug tramp/plink USER#IP*
The level 10 verbosity might be too overwhelming - you can experiment with lesser levels (smaller numbers) to see if it reveals what the problem might be. Check the docstring for tramp-verbose.
Good Luck!
Related
I find myself doing this often:
launch emacs
shh into a server by C-x C-f [RET] /ssh:me#aserver.com:filetoedit.py [RET]
C-x 2 to split windows
C-x o to switch to top window
M-x shell to start a shell on my ssh connection
I there a way to automatically replicate this process on startup? M-x desktop-save doesn't seem to be doing this for me.
Despite my enthusiasm for emacs, I recommend you to take a look at "tmux".
You run emacs in tmux only once. Later on, say when you are back in the office the next day, you simply re-attach to the tmux session and will find your emacs instance is still there.
You don't really specify a lot about your setup, and I agree tmux may help. In my case, I do a version of what you are asking about daily. I'm running GUI emacs 24 on my Mac, I'll be connected to work via VPN with several tramp buffers and shells open. Then I'll just sleep the Mac, commute to work, re-establish the VPN connection and then continue as if nothing happened with the tramp buffers, and after running M-x shell in the shell buffers, continuing as if nothing happened.
To repeat this for several file/shell pairs I would probably save the window config to a register with C-x r w X and C-x r j X for different values of X.
Some time ago I opened a file via tramp. That is, effectively via ssh/scp. It still is not finished and I would like to stop the reading. Yet C-g does not work. Apart from killing emacs (which seems quite unethical to me, it also destroys my M-x shell s), do I have any other option to stop the loading?
Note that the server does not hang. And I do not want any timeouts like in this question.
If you can find the corresponding ssh / scp process ID, you can kill just that.
If neither C-g nor C-cC-c are interrupting, but Emacs is still responding to M-x commands, you can kill the connection or the whole buffer.
The TRAMP manual suggests that the following M-x commands may be of interest:
M-x tramp-cleanup-this-connection
M-x tramp-cleanup-all-buffers
I am trying to debug an Emacs program performance wise. In particular, I suffer an extremely long startup time (~5' compared to ~1' for a bare Emacs) on a remote connection via WLAN, cellphone etc. In this context, any message written is no help, for the display is not refreshed at all.
What I would like to do is to write onto the "standard output" of the Linux process. I am aware of the --batch mode but this is no help to me because I want to use Emacs interactively.
So how can I write messages out to the Linux-standard output (as opposed to the Emacs standard output)?
You can output to standard error like this:
(print "hello world" #'external-debugging-output)
or
(princ "hello world" #'external-debugging-output)
This can buffer, so be careful.It's not possible to output to standard out at the moment. I'm going to add that, I think!
Start emacs as a daemon (emacs --daemon) and any messages during the start-up sequence will be sent to stdout or stderr, as described by lunaryorn.
Connect to the server with emacsclient
The simplest way to kill the server is M-x kill-emacs RET
For details see C-hig (emacs) Emacs Server RET
Works for me in centos 6.8 (GNU Emacs 23.1.1):
(append-to-file "here I come to save the day\n" nil "/dev/stdout")
Try also using "/dev/tty" in place of "/dev/stdout":
Unclear from question if you intend to redirect "emacs -nw" stdout to a file and monitor that file externally (then use "/dev/stdout"); or are ok with writing to "/dev/tty" thus polluting the self-same tty of the main "emacs -nw" display.
If starting a GUI version of emacs, in such a way it may lose attachment to originating tty, can abuse environment variables to communicate an originating shell's tty to elisp.
This works for me using Aquamacs in Mac OS X. Launching from a bash shell:
$ MY_TTY=$(tty) open /Applications/Aquamacs\ Emacs.app &
then in emacs:
(append-to-file "here I come to save the day\n" nil (getenv "MY_TTY"))
I have setup tramp mode with emacs, have been working using that mode for awhile, recently I start getting following error where I am unable to open any files.
Loading /etc/emacs/site-start.d/50sml-mode.el (source)...done [3 times]
For information about GNU Emacs and the GNU system, type C-h C-a.
Tramp: Opening connection for toolserver using scp...
Tramp: Sending command `exec ssh -e none toolserver'
Tramp: Waiting for prompts from remote shell
Tramp: Sending command `exec ssh -e none toolserver'
Tramp: Found remote shell prompt on `toolserver'
Tramp: Opening connection for toolserver using scp...done
byte-code: Couldn't find exit status of `test -e /home/FILE_NAME.py'
I have re-name the actual file to FILE_NAME.py
Actions taken:
I deleted the .tramp_history file but that didn't fix the problem.
try using the scpx or sshx protocol instead.
try (setq tramp-verbose 6) and check the output buffer to see what's really happening (C-h v tramp-verbose to see the levels), then proceed from there.
Sometimes, it's because my ssh-agent is dead. Restarting it solves the problem.
Sometimes it's because TRAMP still thinks the connection is somewhat usable when it's not. When this happen, I do M-x ibuffer * * D RET to kill all the TRAMP buffers so it starts over.
If none of this works, try to use latest TRAMP from melpa or to reinstall it. TRAMP works pretty fine out of the box, maybe you tweaked something that broke it?
I am attempting to use ESS with EC2. I start an instance in the EC2 console and then ssh into the instance.
M-x shell
cd ~/.ec2
ssh -i zmjones.pem root#ec2-23-22-122-35.compute-1.amazonaws.com
Then I start ESS with
M-x ess-remote
Where I select r. However when I attempt to interact with the process I get an error "R process has died." However I can manually enter commands into the shell by pasting commands from my script into the shell.
The process is not correctly associated with the buffer. Try C-c C-z or C-c C-s to associate the current buffer with the process.
If you still experience this problem, would be good to report on ess bug tracker at github or ess-help.