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.
Related
My goal
I'm trying to add "/opt/bin" to the list of paths eshell uses to find scripts. So far I've tried to do this in three ways
Attempts so far
1) (setenv "PATH" (concat "/opt/bin:" (getenv "PATH")))
2) (eshell/addpath "/opt/bin:")
3) (add-to-list 'exec-path "/opt/bin")
The first attempt does add "/opt/bin" to eshell's path (it shows up as the first instance of "/opt/bin:" in the output of calling "which lein" below)
The second attempt also adds "/opt/bin" to eshell's path (it shows up as the second instance of "/opt/bin:" in the output of calling "which lein" below)
I actually have had "/opt/bin" added to my exec-path for a while. I believe I did this so that /opt/bin would be on my path when running the term command to start a shell, this seems to work fine but doesn't help eshell find commands there.
Failing attempts and temporary workaround
You can see in the eshell output below that even though a command, lein, is available on the path eshell recognizes eshell doesn't find the command. However if I create a symbolic link from a directory that is in eshells default path to a script in /opt/bin eshell is then able to find it.
Eshell output
~ $ which lein
which: no lein in (/opt/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin:/opt/bin:)
~ $ l /opt/bin/ | grep lein
-rwxr-xr-x 1 kevin kevin 12538 2019-01-17 07:32 lein
~ $ sudo ln -s /opt/bin/lein /usr/local/bin/lein
[sudo] password for kevin:
~ $
~ $ which lein
/usr/local/bin/lein
I would prefer not to have to create symbolic links in /usr/local/bin/ just so that eshell can find scripts in my /opt/bin. Note even after restarting emacs it finds the symbolic link not the script in /opt/bin. This is occurring in a GUI instance of emacs-25 on linux mint debian (v9.3) edition.
Question:
How do I get eshell to actually check eshell path instead of the some default list of directories? Should I be updating a different path variable?
Looking at the source of eshell/addpath, it uses setq on eshell-path-env, which is a buffer local var. This means that if you use eshell/addpath, it has to be executed in the context of each eshell buffer. The best way to do this is to use a mode hook.
(defun jpk/eshell-mode-hook ()
(eshell/addpath "/opt/bin"))
(add-hook 'eshell-mode-hook #'jpk/eshell-mode-hook)
I'm not super familiar with Eshell, so I'm not going to say this is the best way, but it should work. eshell-path-env is set from (getenv "PATH") initially, so it's weird that setting PATH env var doesn't work (unless you're doing that after loading eshell).
One way:
Assuming you are running emacs in a terminal emulator or tty; then you can just add /opt/bin to your $PATH. Eshell uses your $PATH to find external commands. Not sure how it works for GTK version.
I tried M-x gdb RET gdb -i=mi --args myexec -d 2 -tl 10 -ba 100
Error: you did not specify -i=mi on GDB's command line!
Is there something wrong with my syntax here? I usually run gdb exactly like that but without the -i=mi flag. I can ofc just run it without args and specify them at the gdb prompt, but that seems annoying to do since I want to be able to launch the debugger with a key binding...
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!
I have a 32-bit desktop, where my copy of emacs is running.
I'd like to be able to debug a program running on a very stripped down qemu 64 bit virtual machine.
The virtual machine has an ssh port 24054, which gives me passwordless root access, and it does have gdb installed.
And it has the directory which my desktop calls ~/myco/chip_test mounted as /9p
So if I make a hello.c file in ~/myco/chip_test,
then go to the 64 bit machine in which the VM will run, and compile it with:
$ gcc -o hello -g hello.c
then start the virtual machine, and on my 32-bit desktop run
$ ssh -p 24054 root#anvil 'cd /9p && gdb ./hello'
Then gdb runs perfectly in command line mode in a window on my desktop.
So now of course I want it to run under emacs, because the command line gdb is a bit hard to read, and I'd like to see my cursor stepping through the file, and have windows with watch variables and so on.
So I try M-x gdb
Run gdb(like this): ssh -p 24054 root#anvil cd /9p && gdb --annotate=3 ./hello
And I get a debugger window up in emacs and everything looks right, in fact I can even set and remove breakpoints by clicking in the fringe of the ~/myco/chip_test/hello.c file in my local emacs, which is the same file as what gdb sees as /9p/hello.c, but the moving cursor doesn't appear or move around, so the whole thing is fairly useless.
So I think that emacs/Gud doesn't quite realise that ~/myco/chip_test/hello.c is the file that the debugger thinks is /9p/hello.c, although obviously something interesting is happening since I can set breakpoints, and so I wonder if there is a way to get one or another programs in the loop to translate the filenames so that everything just works.
Any ideas, or am I just going about this all wrong?
You'll get much better results if you either
mount /home/<user>/myco/chip_test on /home/<user>/myco/chip_test in the
VM (so the source paths match exactly), or
run gdbserver in the VM, and connect local GDB to it.
I'm using Aquamacs and started the emacs server with M-x server-start. My emacsclient connects just fine. However, when I start another ssh session (on the same pc) it cannot locate my socket-name / server file. It's not in ~/.emacs.d/server/server where I would expect it.
How can I find out which server-file / socket-name the emacs server is currently using?
This is my working configuration:
.emacs
(setq server-socket-dir "~/.emacs.d/server")
(server-start)
em.sh
location="/`whoami`#`hostname`:$(readlink -f $1)"
ssh <YOU#LOCAL-WORKSTATION> emacsclient -n -s '~/.emacs.d/server/server' $location
The variable server-socket-dir (atleast on GNU Emacs) is what holds the location of the socket. The socket file in my case is simply called server.
It's in $TMPDIR/emacsXXX/server where XXX is a number that depends on the version of Aquamacs you're running
This should also fix your problem without needing to manually delete the file.
M-x server-force-delete