Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I once used emacsclient as my editor from the command line, but it bothered me that it would hang the terminal window while I was working in emacs. I tried backgrounding the process by running emacsclient somefile.txt & but that lead to a lot of "broken pipes". I didn't know what those were, but my files were getting corrupted. I've learned to deal with the issue.

Recently, I also started using latexmk for compiling research papers. I tried latexmk -pvc & to run a continuously-compiling process in the background, but again I ran into the issue of "broken pipes".

While I'm usually in a tabbed terminal and can work around a busy window by starting a new one, I really like having my full command history. Since most commands get typed into the first terminal window, it has the best history.

But I keep finding myself working remotely on machines with no screen emulators. Is there a baked-in way to multitask in a single terminal window?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

As far as I know, the only reason you would get a broken pipe with a backgrounded process is if you close the terminal window that started it. Even though it's in the background it's still attached to your terminal by pipes to stdin and stdout. If you close, log-out, or exit the terminal, the process's pipes will get broken, and the process will receive a signal to terminate (SIGHUP I believe).

The solution to this would probably be to use nohup. nohup redirects the new background process's stdin, stdout, and stderr to files and prevents the process from being sent SIGHUP.

To use it you can run nohup emacsclient somefile.txt & or if you want to avoid the nohup.out and nohup.err files that it uses to capture stdout and stderr, you can get rid of the output entirely with nohup emacsclient somefile.txt &> /dev/null &.

Since that gets a bit unwieldy to type just to edit a file, you will probably want to stick that in an alias or shell script.

share|improve this answer
    
I didn't know about nohup. I've also been perplexed in the past by code snippets utilizing /dev/null, but never bothered to look into it. Thanks for teaching me something. :) –  jrhorn424 Mar 5 '11 at 18:13
    
Glad I could help, best of luck! To clarify, the &> /dev/null bit attaches both stderr and stdout to the file /dev/null. That means it's basically leaving them disconnected, since /dev/null is a special device that discards all input. –  cecilkorik Mar 6 '11 at 4:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.