I am using TRAMP to work on a remote host that has a very weird PATH. I was wondering whether it was possible to customize the PATH used by TRAMP to find the binary files only for this host?
Now, I'm using:
(add-to-list 'tramp-remote-path "/some/weird/path/bin")
but it also applies to any other host without this funky PATH, thus messing up all the other hosts' PATHs.
I'm sorry, but this is not possible yet. There is an item on Tramp's todo list for supporting connection-local variables, but this is not implemented yet.
Alternatively, you might set this in the $PATH env variable in your remote .profile. Then you instruct Tramp to use this, by adding tramp-own-remote-path to tramp-remote-path.
Related
I use tramp to connect to my company's servers.
I would like to customize my functions to work differently if I am accessing local files vs remote ones.
Is there a variable I could check if the buffer I am accessing is on a remote server or my local machine?
Something like:
if(TRAMP_CONNECTED)
Do this
else
Do that
The most robust check is likely default-directory. This variable is always set buffer local. If (file-remote-p default-directory) returns non-nil, your buffer is under Tramp control.
I have followed (and partially adapted) the recommendations in Open file via SSH and Sudo with Emacs
My custom.el contains something like the following:
(custom-set-variables
'(tramp-default-proxies-alist (quote (("my-sudo-alias" nil "/ssh:user#host")))))
However when I try to visit a remote file say sudo:my-sudo-alias:/etc/whatever I get the following error: Method `scpc' is not supported for multi-hops.
How do I fix this?
Perhaps something else in your proxy list is interfering?
What does C-h v tramp-default-proxies-alist look like?
You might also have scpc set as your tramp-default-method. I don't think that should be an issue in this case, but I'm not certain of that.
Did you try the ad-hoc approach that I detailed in the Q&A you linked to?
If that doesn't work, try emptying the proxy list, and then trying it again.
Note also that the scpc & rsyncc tramp methods are deprecated in the latest Tramp (ControlMaster is now used automatically if it is available).
I am working on a remote Linux machine a little complex right now. Firstly, I use Putty to login a jump machine which is also a Linux system in my office, then I use command go to jump to the remote machine outside of my office. There is also a key file I need when using putty. The Linux jump command is like this:
ssh 119.11.11.11 -p 22
The IP should be changed according to the remote machine IP.
The usual way of my development is always using Emacs Tramp to edit files remotely.
I don't want to copy my Emacs config files to the remote machine, for it is a little bit hard to sync the config files between machines. I also don't want to download the files to local for it isn't conveniently to debug.
In this suitation, how can I use Emacs to jump to the remote machine? Is it possible to do the jump by using Cygwin, Putty or something else?
My desktop is Windows 7, and my Emacs is 24.2
Assuming you can't SSH directly to the destination server, it sounds like you could resolve this by configuring a multi-hop proxy for tramp.
I've only tried that once, but it was for a slightly different situation, and I had problems getting it working; so I'll just point you at the documentation, and leave it to someone more knowledgeable to provide other details if need be.
C-hig (tramp) Multi-hops RET
I would strongly recommend using either scpc or rsyncc as the method for the second hop, if possible, as that will automatically utilise SSH ControlMaster to keep the connection open, which dramatically improves Tramp performance.
I'm not sure whether or not there's an equivalent to that for PuTTY/plink? I do know that Cygwin isn't able to support ControlMaster for some technical reasons (or at least this was the case a few years ago), so using that probably wouldn't help.
Another alternative Cygwin's SSH and PuTTY is to host a Linux(*) VM on your Windows box and run Emacs inside that (which means you can use Linux's SSH and ControlMaster). Cygwin can provide an X display in that instance. That's complicating matters, of course, so I would certainly try out the simpler options first; but if performance is lacking, and your local PC is reasonably powerful, the VM approach might surprise you.
* or similar
Ignoring Tramp entirely, sshfs is often used to mount a remote filesystem locally, in which case Emacs doesn't even know that it's talking to a remote server. I've never used it myself, and certainly not on Windows, but it could be worth a look as well.
Lets say I have an Emacs-Server running on some remote server, with all the libraries and software necessary for running my application.
Then I want several clients to connect to that remote machine, using Emacs-client. Does each client need a full Emacs installation, or is there a minimal installation that is just enough to communicate with the remote server, where all the action is?
Could this (Emacs-)client installation be so minimal, that almost all software-updates can be done on the server, without affecting the Emacs-clients?
Is there a reason not to run the clients remotely as well, and simply use a local display? That way, pretty much all you need on the local machines is the ssh client and the X Window server.
ssh -X (user)#(server) "emacsclient -c"
Edits for the comments:
This command starts a new client to connect to an existing Emacs server (which it assumes is already running). You can use "emacsclient -a '' -c" to automatically start emacs --daemon if there is no existing server, but I don't know whether you want the connecting user to be starting the server.
In fact, I'm pretty unsure about the whole multi-user side of this to be honest, as I've never done that before. Authentication for the above is handled by ssh, but there may well be subsequent permission issues to deal with, or similar, when the server and the clients are started by different users.
This approach should be possible with Windows/Cygwin as client and/or server, as Cygwin provides Emacs, OpenSSH, and X.org packages. (I regularly use Windows/Cygwin as a local display for Emacs running on Linux.) It may be harder to set up, though, and any permissions issues are probably different when you're using Cygwin.
I'm less sure how this would work without Cygwin. NTEmacs certainly won't talk to X.org, so I imagine you'd be terminal based in that instance. (There are probably other options, but Cygwin sounds to me like the best-integrated approach to using all of Emacs, SSH, and X on Windows).
Lastly, I imagine you're probably getting your "Connection refused" error because localhost is not running a sshd daemon? I would say that configuration of ssh is outside the scope of this question, but there are lots of resources online for that.
Depending on what you're trying to achieve, you may be able to use a combination of Emacs and Screen. By starting up Emacs from Screen on the remote machine and detaching from it, you can subsequently re-attach from a different machine that doesn't have Emacs. Again, whether this will work for you or not depends on what you're trying to do; however, for many Emacs use-cases, this can be very effective. If you're not familiar with using Screen in this manner, here is some reading material:
screen - The Terminal Multiplexer
I am not sure that would be possible. emacsclient uses tramp to connect to a remote server, and just by looking at the number of requires in the tramp elisp files (41) it seems very unlikely. You can try it yourself with the following:
zgrep -oE "\(require '[a-z-]+\)" *el.gz | sed -e 's%[a-z0-9-]\+\.el\.gz:%%g' | sort | uniq -cu | wc -l
I'm not an expert in emacsclient, but I don't think is was designed to do what you're looking for. I think the general use case is that emacsclient allows you to redirect new requests to open a file with emacs to a persistent emacs process to avoid what may be a bit of an overhead in startup time. You seem to be looking for more of a true client/server relationship.
I think to meet the goal you're aiming at you'll probably need to look a little outside emacs, probably a project unto itself - 'emacsRemoteClient. It boils down to one or two models; the file you want to edit would need to have it's path sent over to the server machine so that emacs could do some sort of remote tramp access & then spawn the xwindow locally (using the local X env or requiring an x server on windows)... or two, transferring the file to some temp location on the server box and again spawning the remote x window locally (followed by syncing the changes between the tmp & local file).
Would be cool to have something like that... but suspecting it'll involve a bit of work. Maybe we just need a version of emacs written in javascript and it can live in the cloud or on your browser... oh to have emacs keybindings in the browser ;-)
-Steve
I have seen a few suggestions on making emacs portable (on Windows). I have this in my site-start.el:
(defvar program-dir (substring data-directory 0 -4))
(setq inhibit-startup-message t)
(setenv "HOME" program-dir)
I changed the HOME variable so that not only my .emacs init files (and other init files) are read, but everything generated by emacs will stay in the program directory, not needing me to specify the path for everything one by one.
Well this works well but the emacs server is not working; I get error message "no connection could be made because target machine actively refused it." If I don't change my HOME var then emacs server works. Is there way to fix this?
Quoth the Emacs manual:
When you start the Emacs server (by calling server-start), Emacs creates a file with information about TCP connection to the server: the host where Emacs is running, the port where it is listening, and an authentication string. emacsclient uses this information if it needs to connect to the server via TCP. By default, the file goes in the ~/.emacs.d/server/ directory. You can specify the file name to use with the `-f file' or `--server-file=file' options, or by setting EMACS_SERVER_FILE environment variable to the file name.
In other words: wherever you're calling emacsclient from, you'll have to tell it to use the file in ${program-dir}/.emacs.d/server/, either with -f or setting the EMACS_SERVER_FILE environment variable. (In the environment in which you're starting emacsclient, not within Emacs.)
[You could also tell Emacsclient to look in the right place with -s for "socket", but that doesn't work on Windows. And on Unixes (at least on Mac OS X with Aquamacs) the socket would be somewhere like /tmp/emacs501/server (501 is my UID).]
[Oh, BTW, take a look at this question: How can I have a portable Emacs? Maybe something will help you, or maybe you have something to add to it :-)]
There is an initial packaging of a Portable Apps version of emacs 23.2 here. Initial test works here.