When using start-process with Emacs on Windows XP, deleting the process or killing Emacs also kills the subprocess -- e.g., viewing a PDF with another application.
How would one go about removing a process from the list of active processes within Emacs, without sending a kill signal to the subprocess -- i.e., leave the subprocess running, but tell Emacs to forget about it?
Here is a related thread that discusses using w32-shell-execute as an alternative to start-process: In emacs, how to execute external command not as a emacs process? I have verified that w32-shell-execute is a viable alternative for Windows XP.
I am very fond of start-process and would still be interested in knowing (please) whether it is possible to delete a process from Emacs without killing the corresponding subprocess.
Related
When I type emacs & in X11, a new window doesn't open. Instead I just get the PID of the process. This illustrates what I mean.
bash-3.2$ emacs &
[1] 38624
Why is this happening and how can I get emacs to open in a separate window?
You can't start terminal Emacs as a background job -- it needs to interact with the terminal. Whenever a background job attempts to write to the tty, it is immediately stopped.
I would expect that your next input into the terminal would have resulted in a message similar to this?
[1]+ Stopped emacs
(which would have been useful).
You could then foreground the job with fg.
Running emacs & only makes any sense with GUI Emacs.
Some time ago I opened a file via tramp. That is, effectively via ssh/scp. It still is not finished and I would like to stop the reading. Yet C-g does not work. Apart from killing emacs (which seems quite unethical to me, it also destroys my M-x shell s), do I have any other option to stop the loading?
Note that the server does not hang. And I do not want any timeouts like in this question.
If you can find the corresponding ssh / scp process ID, you can kill just that.
If neither C-g nor C-cC-c are interrupting, but Emacs is still responding to M-x commands, you can kill the connection or the whole buffer.
The TRAMP manual suggests that the following M-x commands may be of interest:
M-x tramp-cleanup-this-connection
M-x tramp-cleanup-all-buffers
Sometimes I want to run emacs in batch mode, and in such cases I want to avoid doing certain things in my init, such as starting the emacs server. Is there any way to test from within Emacs Lisp whether Emacs is running in batch mode?
From http://www.gnu.org/software/emacs/manual/html_node/elisp/Batch-Mode.html
-- Variable: noninteractive
This variable is non-nil when Emacs is running in batch mode.
In Emacs, sometimes I start a shell with ansi-term, and then from this shell I run IPython (another shell) that enters a long loop printing a long, long output.
When this happens, I often want to sendSIGINT to stop the script that IPython is running, but sometimes this takes way too long for IPython to capture Ctrl+C Ctrl+C (there are times when IPython never seems to listen to it). Interestingly, this does not seem to happen when I run it from a regular terminal.
Why is this the case? Is it an Emacs or IPython problem?
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.