I used to be a comfortable emacs user and for close to 10 years I completely got away from using emacs (I know its a shame) but I have a wage memory of setting something in .emacs to open remote files in a server via local emacs.
Just to make the scenario clear:
Login to a remote server (ssh) -> emacs somefileInRemoreServer.file &
File get open using the local version of emacs.
My questions are:
Is this possible?
how can I accomplish this?
I have both mac and ubuntu on mac I use Aquamacs. It would be a great help if I can get instructions on both versions.
I'm not sure whether you want to ssh prior to using emacs or ssh using (in) emacs.
If you want to let emacs do all the work check out the links added by phils, TRAMP mode is the way to go for remote editing IN emacs.
If you want to use ssh to mount a remote filesystem (resulting in "local" editing with emacs) you should check out sshfs (man, wiki).
I think it comes with pretty much any of the current distros (or can be installed easily otherwise). It is a fuse extension which allows to mount a remote directory to a local one without any further requirements on the remote side than ssh.
I do like TRAMP for editing one or two files but using sshfs is great for working on a whole project directory which is placed remotely and which you do not want to sync using another method.
Related
Is it possible to use $ code . in remote server ssh session just like I do in WSL when I want to open current working directory in remote host in local VSCode?
ADDENDUM:
In local WSL, I can issue $ code . and that would open the current directory in VSCode which is installed on Windows 10.
I am trying to get the same behavior in another remote Linux which I have connected to remotely through ssh. So when I am on that remote machine and issue $ code . it would open that directory in VSCode installed on local window.
I don't imagine this would be simple to do but I certainly share your desire to want to be able to do it.
Problem
Here's an explanation of why it doesn't work, and a hint at why it's probably quite a difficult thing to setup:
The way code . works from WSL (or PowerShell) is by launching VS Code in the given directory (passed as the first argument as the dot).
When you run code from WSL it uses wslpath to convert the path to the Windows accessible one, and the WSL magic executes code.exe (which is, after all, a Windows binary and not a Linux one) in Windows with the WSL path (\\wsl$...);
Theory
In order for this to work you need to achieve three things:
Work out which remote you're connected to, and be able to pass that information to vscode
Execute code.exe on your local machine, but from your remote terminal
Ideas
A couple of ideas you could play with if you wanted to try and implement it:
A script on your remote could output a vscode:// URL for you to click (or find a way to get your client to auto-load it).
You might be able to use a forwarded port in your SSH session to contact something on your PC (perhaps custom made, or maybe with Windows RDP or a telnet/ssh server perhaps?)
Perhaps mount a local directory as part of your SSH connection (I don't know all the edges of SSH but it does a lot of cool stuff! SCP might help?) and be able to execute/trigger things?
Just some musings! It's not something I need enough to put any effort into it, but I came across your question looking for something else and found it interesting. Hope that's helpful to anybody, any thoughts/feedback is welcome!
TRAMP (Transparent Remote Access, Multiple Protocols) is a package for editing remote files, similar to AngeFtp or efs. Whereas the others use FTP to connect to the remote host and to transfer the files, TRAMP uses a remote shell connection (rlogin, telnet, ssh). It can transfer the files using rcp or a similar program, or it can encode the file contents (using uuencode or base64) and transfer them right through the shell connection.
It seems like as of now there is at least one similar package to Tramp mode for VSCode. I couldn't directly find in the documentation how you would open a remote shell inside VSCode, but it seems like it would have to be possible given the rest of the plugin.
https://code.visualstudio.com/docs/remote/ssh
https://code.visualstudio.com/blogs/2019/10/03/remote-ssh-tips-and-tricks
I have a terminal menu in VSCode that I can open up and directly ssh to stuff, so that seems to cover both sides of the "Tramp" mode usage
You can use FUSE for a somewhat similar effect. It's not editor specific, but mounts remote file systems via SSH, FTP and whatnot directly to your local file system so you can use it with any Editor.
You didn't mention on what operating system you, but here's the link to the version for macOS: https://osxfuse.github.io
My school (UCSB) has us use PuTTY to remotely access our CS account that's ran on the school's server. Whenever I attempt to use the school's emacs via PuTTY, it's extremely tedious because it's all in text user interface. I do have an option to use Xming to access the GUI Emacs, but that's incredibly slow since it still relies on the server's emacs. So now I'm fed up of relying on using WinSCP as a text-editor (I know it isn't suppose to be a text-editor) on my laptop, and want to use emacs without the terrible interface or speed. I finally went to the GNU website to download a local copy of emacs on my laptop. However I can't do anything with it unless I constantly transfer my files from the school's server to my laptop for editing, and vice-versa for compiling, which can be very tedious.
So, is there a way I can use PuTTY to access the files on my school's account and then have them opened using my local emacs? Or is there any other ideas or tools to help me with my situation?
TRAMP would be the way to go. In order for TRAMP to use PuTTY by default do this
(setq tramp-default-method "plinkx")
After that you can access the files or use dired on your remote host by using paths like
/name_of_Putty_session:/path/on/remote/host
On a daily basis I:
use multiple workstations running either Linux, Windows, or MacOS X
edit files on additional Linux hosts that are not any of the workstations mentioned above
The only common element here is that the internet connects all of these hosts: workstations and servers. I can keep all of the config files in sync on my workstations too and can run an X server on all of them. What's the right way of running emacs? I don't want to sacrifice any features.
In my ideal world I can type 'emacs foo.txt' on a remote host and some magic happens via X forwarding to display the file in my workstation's existing emacs session.
Non-solutions
tramp: when I'm manipulating a remote host an editor is just part of my workflow. I need a terminal open so I can run other commands quickly. tramp is all wrong for this.
ncurses emacs: sucks, I want the graphical kind
If you don't have a positive answer to my question, please don't just guess. Thanks.
Have you tried tramp with eshell? You can "cd /remote.host:/some/path" and edit files from there, and if you type a non-built-in, it fires up a ssh pipe to run it. Quite slick.
I fail to see why tramp is not a solution. You can edit using tramp, and do whatever you need in a terminal using xterm+ssh.
Well, if you can setup X clients on your Windows and OSX boxes, you should be able to run an X version of emacs on any of those platforms and set the display back to your workstation. That would give you your nice WIMP interface.
However there are a couple of solutions to keeping a terminal open to the same box. One is to just telnet into it twice. Once for your emacs session, and once for a shell.
The other option of course is to use meta-x shell to bring up a shell buffer inside of emacs. A true emacs guru prefers to run their OS inside of emacs, rather than the other way around. :-)
The approach I use is based on source controlling the Emacs scripts and important common files (using Git). This gives me a consistent code base so I don't have to remember which host has which script or file (or version of what I'm looking for). Git is particularly well suited to supporting this mechanism and I've pretty much got in the habit of updating the master origin repo daily. Within the scripts (both Emacs and bash shell scripts) I use machine tailored code to handle local requirements. This system has been in place now for well over a year and I find it to be quite effective. This is a technique I've seen recommended for some number of years. I found it clunky with CVS and Subversion but git feels tailored for the job. That said, I like the solution you selected as a complimentary tool and look forward to adding that to the mix.
I use Emacs remotely using X-Server in a Windows client and Linux server. I noticed that I can halt it using ctrl-z and then type fg 1 to get it working again. Is there some way that I could get it to halt on the machine that I am on, and then log into a different machine and start where I left off? When I start a new ssh session, the emacs job isn't associated to my terminal. There must be someway to "steal" it.
Also, maybe there's an Emacs feature that will do basically the same thing. However, I think closing and re-opening all my files and buffers would take quite a while.
Expanding on the idea of using emacsclient, you can look at what what someone did to solve the problem of editing a file from a different machine than where (s)he started running Emacs.
As of Emacs 23, you can run emacsclient in terminal windows using the -nw option.
Other solutions you might want to try are to use:
gnu screen
vnc
For years I used screen to "attach" and "detach" from a virtual terminal that sounds like your usage model. If you have the ability to use graphics... vnc is really great, just do your work in a vnc session and connect to it any machine.
And your last idea is already implemented by the package desktop (which is bundled with Emacs). Take a look at the wiki page for session management, which includes other alternatives to desktop, as well as add-ons for desktop to lazily load files.
You can run emacs as a server, and use emacsclient to connect to it. You can open multiple connections to the same emacs server, via ttys or X11.
When doing this, C-X C-C will close your connection, and leave the server running.
A simple way to do this by invoking emacs as follows. This will connect to the server if one is running, or create one.
emacsclient --alternate-editor="" -c
Sometimes I will be at work and have to run out the door leaving my Emacs session as it was. Later, I will open an Emacs instance to the same machine (usually using remote SSH) and find that I have files open in Emacs. Now the good news. Emacs allows you to "steal" those files using M-x recover-this-file. I recommend one of Trey's solutions if you can plan ahead. If not, you can use this recover file technique to keep progress moving.