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.
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.
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!
Occasionally when using emacs in term mode I will mistakenly run emacs file instead of just opening the file. This will create a nested emacs client inside the current client. My problem is how to close the inner client only?
Answer
You should be able to C-z out of it, then kill it with
kill %1
Explanation
C-z will suspend the current process, assigning it a job number and returning you to the shell.
The jobs command will show you the current jobs and their numbers. kill allows you to kill a process by its job number using the %n syntax.
Just use the command M-x kill-emacs inside the inner emacs. Backgrounding and killing it works fine but it is a little bit more hackish.
You should use the top Emacs. Starts emacs with:
emacs --daemon
Starts all frame with:
emacsclient -c
From your term:
emacsclient -n
Or you should use eshell instead.
I have code on a compute node of a cluster. I can't ssh directly to the compute node so I first set up an ssh tunnel with
ssh -f cluster.master.node -L 2222:cluster.compute.node:22 -N.
Next I visit the file with
C-x C-f /ssh:user#localhost#2222/path/to/blah.c.
Finally I do
M-x gdb.
In emacs 23 I would do
Run gdb (like this) gdb --annotate=3/ssh:localhost#2222:/path/to/program
but documentation for the gdb function in emacs 24 says "The command-line
options should include -i=mi to use gdb's MI text interface. Note that the old "--annotate" option is no longer supported."
Running
gdb (like this) gdb --i=mi /ssh:loalhost#2222:/path/to/program
seems to work, but when I try to run the program I get "Starting program: /misc/home/joey/git/proteus/proteus /dev/pts/5: No such file or directory." The problems seems to be with the non-existent /misc/ directory prepended to the path of the executable. Even when I do a cd to /home/joey/git/proteus/ the response is "Working directory /home/joey/git/proteus (canonically /misc/home/joey/git/proteus)."
Can I remotely debug my program in Emacs 24 or should I go back to 23?
Try M-x gud-gdb RET: it will give you the old Emacs-22 behavior.
Assume you work on a remote server from a local emacs shell (started with M-x shell). If you execute a process which takes too long (for example an ls in a directory with a huge amount of files), you would like to stop that process (in the terminal one would use control-c). I tried C-c C-c but that kills the whole shell... How can I only kill the running process on the remote server and not the whole shell?
Update
Step-by-step:
1) M-x shell (execute on local machine)
2) ssh mylogin#myremotemachine.foo.bar (execute on local machine)
3) sleep 60 (execute on remote machine)
4) C-c C-c (execute in the current shell)
=> instead of still being on the remote host and just the sleep command being killed, the whole remote connection is closed and you are on your local machine again.
When I follow the steps you listed, I find myself back at the remote shell prompt. I'm using Emacs 23.1.1.
I find that typing C-q C-c RET also interrupts the remote process, again leaving me at the remote shell prompt. You might try that as an alternate approach.
It is unclear to me if you want to kill the command from within emacs, but you could alternately open another connection or window (if you are using screen or tmux) and perform the standard
ps aux | grep hungprocess
and then
kill hungprocess_pid
For some reason I kept thinking that such a method wouldn't work and that I'd end up taking down emacs as well. I have used such a method multiple times when I haven't set up my gpg pinentry agent when opening a gpg encrypted file in emacs. Emacs/gpg will try to spawn a GUI and therefore hangs emacs, waiting for input in the GUI when I am remotely ssh'ed in.