I'm looking to set up an emacs server such that the files specified by emacsclients
are relative to the emacsclients' filesystem and not the server's filesystem. For instance, if I set up an
emacs server on a machine "darkstar" and I connect to this server through an emacsclient
on "brightstar" with the command
emacsclient -nw '~/fantastic'
The emacs server will attempt to edit the file ~/fantastic on darkstar and not on
brightstar. Id like the reverse of this. I'm open to all sorts of zany suggestions.
*Background note:
I want an emacs process that tracks all the buffers I open on various
machines, keeps track of my color settings, bindings, etc. I want all of this
available and replicated on any arbitrary machine with emacs. The emacs server
seems to do just this but without the ability to edit client's local files!
You should be able to set to set up a shell function which uses tramp, like
edit-local() {
emacsclient -e "(find-file (expand-file-name \"$1\" \"/ssh:$USER#$(hostname):$PWD\"))"
}
Of course you may have to change the tramp protocol to whatever you have setup.
Does the remote machine (the one running Emacs) have mounted the filesystem of the local machine? If so, you could issue something like:
emacsclient --eval ´(my-open-file "~/fantastic" "my-local-machine")´
You could then write the function my-open-file that could, for example, open the file //mounts/my-local-machine/home/YOUR-ACCOUNT/fantastic (assuming this is the mount point).
It will require some elisp-hacking and some script hacking (using, for example, Ruby) to build up the emacsclient command-line.
Related
I configured and started an emacs server in TCP mode:
Added (setq server-host "10.16.184.33") and (setq server-use-tcp t) to .emacs
ran emacs --daemon
On the same host, running emacsclient -t brings up an emacs frame in the current terminal, and running emacsclient -c brings up a new graphical client frame, as expected.
On a different host, running emacsclient -t -f ~/.emacs.d/server/server appears to successfully connect to the remote emacs server, but no frame is created in the terminal:
$ emacsclient -t -f ~/.emacs.d/server/server
emacsclient: connected to remote socket at 10.16.184.33
At this point, emacsclient is running in the foreground, and a Ctrl-c stops it with a SIGTERM.
the value of the server-client variable shows that remote emacs client is connected:
server-clients's value is
(#<process server <10.16.184.33:52710>> #<process server <10.16.177.8:59460>>)
Things that I've checked:
versions of Emacs and emacsclient: all 24.3
when swapping which machines are the server and the remote client, the same problem occurs, except...
emacsclient prints an extra error message
emacsclient: connected to remote socket at 10.16.177.8
*ERROR*: Could not open file: /dev/pts/26
Any ideas of what else to check or configure?
There is nothing you could “check or configure”. You simply cannot use emacsclient remotely, because both processes share the frame, which does not work remotely for obvious reasons.
If a client connects to an Emacs server, it does not actually create the frame itself. Rather, it merely tells the server what kind of frame to create, i.e. whether a GUI frame or a terminal frame. The server then creates the frame based on the client's request and parameters.
Specifically, in case of a TTY client (i.e. emacsclient -t) the server attempts to create a frame on the client's TTY. Obviously this won't work if the server runs on a different system. TTYs are local and not remotely accessible.
FYI, the “TCP mode” of the Emacs server was never intended for remote access. It is simply a workaround for systems which do not support local Unix sockets, that is, Windows.
You don't even want to try and make it work, because it's horribly insecure. Being intended as local protocol, Emacs server does neither support traffic encryption nor authentication. By running a remotely accessible Emacs server, you allow any other system to execute arbitrary Emacs Lisp on your machine.
The right way to use Emacs remotely is SSH. Setup an SSH server on the remote system, then connect to the system via SSH and start emacsclient -t in the remote shell.
I am already using Emacs server for some of the problems described in the documentation, For example, I have (server-start) in my .emacs init file, and I have set the EDITOR env. variable to emacsclient so that git and other programs don't open a new instance of Emacs when they need me to type text or log message. This is working great so far.
I am now wondering if I can use Emacs server for something else: I often launch Emacs remotely through an ssh -X session. Sometimes I need to close the ssh session (e.g. I need to reboot my local computer) and re-connect. It would be great if instead of fully closing Emacs for this, I could detach from Emacs, and reattach later.
Is this possible with Emacs server? I believe from things I have read online that the answer is yes, but:
My question:
How can I safely detach from an Emacs server and reattach later?
If you directly start Emacs from within the SSH session, you cannot gracefully detach, because the Emacs process becomes part of the process group created by the remote shell, and if the shell exists it will terminate all processes in its process groups.
However, you can start Emacs in Daemon mode first, with emacs --daemon. Emacs will load the configuration, start an edit server (even without an explicit (server-start) in your configuration), and detach from the terminal. This Emacs daemon will stay alive across different SSH session.
Subsequently, only use emacsclient to connect to the running daemon.
emacs --daemon or (server-start) in .emacs.
Next use emacsclient file, emacsclient -n file or emacsclient -c for just an attaching.
To leave attach as usual C-x C-c.
I wonder if anyone out there uses ssh through the emacs shell. I am able to connect with the remote machine but I cannot open files to view/edit with emacs using 'emacs filename' as the 'Terminal type "dumb" is not powerful enough to run emacs' (normally emacs would open within the console when connecting through the terminal).
Is this a bad idea to try to use emacs in such a way, or is this possible with a few fixes? Thanks much!
It may not be obvious on first sight, but eshell, the shell that is
implemented in Emacs Lisp works fine with tramp:
Welcome to the Emacs shell
~ $ uname -a
Linux local-machine 2.6.30-1-686 #1 SMP Thu Jul 30 14:45:30 UTC 2009 i686 GNU/Linux
~ $ cd /ssh:user#remote-machine:~
/ssh:user#remote-machine:/home/user $ uname -a
Linux remote-machine 2.6.18-6-686 #1 SMP Thu Aug 20 21:56:59 UTC 2009 i686 GNU/Linux
/ssh:user#remote-machine:/home/user $
A couple of ideas
Source the .bashrc explicitly via . ~/.bashrc and/or rearrange your bash init files and ~/.profile so that this gets loaded inside the emacs shell; then running ssh inside the Emacs shell works just fine
Use the emacs-specific Tramp mode to access remote files via ssh inside your local Emacs -- this is useful if you just need to update/touch/edit a remote file so you would not need to open a remote emacs inside the ssh session started from inside your local emacs.
Emacs has term-mode which is full blown terminal emulator you can run emacs in emacs. Anything you run on terminal will run in term-mode
Also emacs has tramp mode which can open files through ssh.
/scp:user#ipOrHost#port:/
it will transfer files back and forth. you just edit them as you would edit local files.
No need for x11 forwarding or other shenanigans.
You could use ssh x forwarding to run a remote emacs and display it on the local computer. I use Xming X Server when I'm on Windows
You could mount the remote filesystem with ssh and open the locally as normally.
For this I use ExpanDrive (commercial app) when on Windows
You could use emacs Ange ftp over ssh it can open remote files over ftp and ssh.
I use this with cygwin when on Windows
I have been struggling with Xming, which works, but as my internet connection is not the fastest I have to wait more 30 seconds before emacs or any X app even shows up. Also scrolling through a buffer after it has been opened will freeze from time to time => Very annoying
Try No machine (nxserver-freenx server/client). There are free edition servers, absolute the best and fastest solution when you want to connect to a Linux box and use xterm and emacs over X. It shows up immediately and responds so fast. Even over a really slow connection :-) Clients are available for Windows, Mac OS, Linux
Emacs option for ssh : c-x c-f /ssh:user#host:/home/path/
For Reference: Open file via SSH and Sudo with Emacs
I want to open a file inside Emacs which is located on a remote server, with sudo powers on the server. I can open local files with sudo via Tramp like this:
C-x C-f /sudo::/home/user/file
But I want to use sudo on the server:
C-x C-f /sudo::user#server/home/user/file
But this gives me sudo powers on my local machine, it asks for my sudo password on the local machine. Is there a way to use sudo on the server?
BTW: Emacs is not installed on the server
As of Emacs 24.3, an analog of the old multi: syntax has been layered on top of the modern tramp-default-proxies-alist approach, meaning that you can once again perform multi-hops without any prior configuration. For details, see:
C-hig (tramp)Ad-hoc multi-hops RET
With the new syntax, each 'hop' is separated by |. The example in the manual is:
C-xC-f /ssh:bird#bastion|ssh:you#remotehost:/path RET
Which connects firstly as bird#bastion, and from there to you#remotehost:/path
/su: or /sudo: on remote hosts
You can also use this syntax to sudo/su to root (or of course any other user) on a remote host:
C-xC-f /ssh:you#remotehost|sudo:remotehost:/path/to/file RET
Important: be sure to specify the hostname explicitly: sudo:remotehost: rather than sudo:: (see below).
As this still uses the proxy mechanism underneath, tramp-default-proxies-alist should now include the value ("remotehost" "root" "/ssh:you#remotehost:")
Meaning that the proxy /ssh:you#remotehost: is going to be used whenever you request a file as root#remotehost.
root is the default user for these methods, but you can of course also change to a non-root user with:
C-xC-f /ssh:you#remotehost|sudo:them#remotehost:/path/to/file RET
Always specify the remote hostname explicitly
You are probably used to using sudo:: or su:: and omitting the hostname. If you are staying on the localhost then this is still fine, but if you are hopping to a remote server then you must specify the hostname for every hop -- even if it is the same as for the previous hop. Always use sudo:hostname: or su:hostname: with remote hosts.
The trap here is that sudo:: does actually appear to work -- however when you do that the HOST for the dynamic proxy entry will be the hostname you originated from rather than the host you connected to. This will not only look confusing (as the wrong host will be displayed in the file paths), but it will also mean that any subsequent attempt to use sudo:: on your localhost will instead be proxied to the remote server! (and the proxy would also presumably be clobbered if you did the same thing on a second server, causing further issues).
In short, don't use :: when you multi-hop!
Emacs 27+
Starting from Emacs 27.1 (or Tramp 2.4.2, if using the GNU ELPA package) the :: case works intuitively, such that /ssh:you#remotehost|sudo:: will re-use remotehost rather than your own local host, and so you won't end up with a bad proxy entry.
In addition, the likes of /ssh:you#remotehost|sudo:localhost: are detected and flagged as user errors.
If you are liable to use a mixture of Emacs versions including versions earlier than 27 (or you are advising someone else who may be using an older version), then it would be safest to continue to treat :: as unsafe when multi-hopping, to avoid potential mishap. (I.e. specifying the correct remote host explicitly will remain the safest approach if the Tramp version is unknown.)
Update: Although this answer solved the original problem, it was written for emacs 20 or 21. For emacs 24, I recommend you use phils's answer because it offers more explanation and is up to date.
I think multi-hop filenames in tramp is what you're looking for.
The first hop would be ssh and the second would be sudo.
Update: Recent versions of emacs support multiple hops using proxies:
(add-to-list 'tramp-default-proxies-alist ("my-sudo-alias" nil "/ssh:user#ssh-host"))
Then invoke by opening:
/sudo:my-sudo-alias:file-on-ssh-host
I had some troubles with the selected answer. However, it worked when I added this line to .emacs:
(add-to-list 'tramp-default-proxies-alist '(".*" "\\`root\\'" "/ssh:%h:"))
And then executed the following:
/sudo:ssh-host:file-on-ssh-host
It was slightly confusing because at one point I was prompted for the "root" password, but entering my user's password granted me access. It also universally works on all hosts on the network. Also, I can still do this to not be root:
/ssh:ssh-host:file-on-ssh-host
From the tramp multi-hops configuration webpage
(add-to-list 'tramp-default-proxies-alist
'(nil "\\`root\\'" "/ssh:%h:"))
(add-to-list 'tramp-default-proxies-alist
'((regexp-quote (system-name)) nil nil))
Then any
C-x C-f /sudo:remote-host:/file
will open file using sudo after logged with the same username of the user running emacs but on the remote machine.
You have to ssh into the server first, then you have to run emacs locally.
Or you can use NFS with no_root_squash, or you can try with emacs server/client, although I have no idea of what may happen (do not use emacs myself)
I would like to be able to use Matlab-mode (matlab.el) to run a matlab shell. The only problem is, Matlab is located on a remote host. Is this even possible? If so, please explain. I'm currently playing around with tramp but to no avail.
Thanks.
I just tried using the emacs matlab mode through ssh, no problem
had to make a script which loads matlab, couldn't just specify the command in matlab.el
so:
/home/second/remoteMatlab:
#!/bin/bash
ssh orac matlab -nodisplay
where orac is the host which has matlab. you can pass commands to ssh here. i use ssh config and key authentication so only need the hostname here
in matlab.el, find
(defcustom matlab-shell-command
and set to eg
(defcustom matlab-shell-command "/home/second/remoteMatlab"
I am not 100% sure what you are doing, but this seems possible. If
you use Tramp (or sshfs, my personal choice) to edit a script on a
remote machine, you will be able to run it on that remote machine. If
you have a *shell* buffer open, it can easily be ssh'd to that remote
machine. If you are doing something REPL-like where emacs sends input
to this buffer that's connected to a process over ssh, it should still
work. If it is communicating with a remote process over a socket, you
can use ssh forwarding to make the socket appear local.
Anyway, there is not much gap between local and remote, so this should
all work out.
Finally, to toe the (GNU) party line... have you tried Octave running locally?
#Yotham : I can't comment yet on earlier answers, but your problem (Script working, malab-shell command in emacs not) may be due to the fact that you didn't delete/rename your matlab.elc file?
This way emacs never gets to know of the change since it prefers .elc over .el files for speed.
Resolved the same issue for me.
cheers
tnt