Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have detached a process from my terminal, like this:

$ process &

That terminal is now long closed, but process is still running and I want to send some commands to that process's stdin. Is that possible?

share|improve this question
Search for retty, neercs, etc. and see also serverfault.com/questions/24425, serverfault.com/questions/115998 – Gilles Feb 16 '12 at 21:39
up vote 56 down vote accepted

Yes, it is. First, create a pipe: mkfifo /tmp/fifo. Use gdb to attach to the process: gdb -p PID

Then close stdin: call close (0); and open it again: call open ("/tmp/fifo", 0600)

Finally, write away (from a different terminal, as gdb will probably hang):

echo blah > /tmp/fifo

share|improve this answer
Very impressive! – Samuel Edwin Ward Feb 16 '12 at 18:59
Can I do something similar to redirect process stdout to a file? – rustyx Aug 25 '14 at 15:28
@rustyx: Untested, but this should work: create a file rather than a pipe, touch /tmp/thefile. Stdout is 1, so call close (1); also, use the correct permissions for writing: call open ("/tmp/thefile", 0400). The echo… is, of course, not needed. – Ansgar Esztermann Aug 26 '14 at 11:25
This is great! I'm using this to send "y" or "n" responses to certain processes that have been completely detached. The detached process has its stdout to a separate window. When I do this trick however, I can see that it does not "receive" the 'y' or 'n' as soon as I echo it, I must quit gdb and detach it and then it receives all of the echos accordingly, so is there a way to perform this without needing to quit gdb before the process receives the input from the fifo? – krb686 Jul 27 '15 at 13:50

I am quite sure you can not.

Check using ps x. If a process has a ? as controlling tty, you can not send input to it any more.

9942 ?        S      0:00 tail -F /var/log/messages
9947 pts/1    S      0:00 tail -F /var/log/messages

In this example, you can send input to 9947 doing something like echo "test" > /dev/pts/1. The other process (9942) is not reachable.

Next time, you could use screen or tmux to avoid this situation.

share|improve this answer
+1 for screen. Even allows shared terminal. – katriel Feb 16 '12 at 13:08
Or dtach if you not need a whole screen. – manatwork Feb 16 '12 at 13:32
There is no way in the standards (POSIX, SUS), but on many (most?) systems it is possible using the mechanisms that debuggers use. See Ansgar's answer. With root you could even do this to other user's processes. – dmckee Feb 16 '12 at 21:30
Doing echo "test" > /dev/pts/1 won't send input to process 9947 - it will output the word "test" on that process's terminal. – psmears Nov 20 '14 at 22:59

EDIT : As Stephane Gimenez said, it's not that simple. It's only allowing you to print to a different terminal.

You can try to write to this process using /proc. It should be located in /proc/pid/fd/0, so a simple :

echo "hello" > /proc/PID/fd/0

should do it. I have not tried it, but it should work, as long as this process still has a valid stdin file descriptor. You can check it with ls -l on /proc/pid/fd/.

  • if it's a link to /dev/null => it's closed
  • if it's a link to /dev/pts/X or a socket => it's open

See nohup for more details about how to keep processes running.

share|improve this answer
It's not that simple. For example, If stdin is linked to a terminal, echoing something to the terminal device will just print what you wrote on the terminal, it will not be transmitted to the process. – Stéphane Gimenez Feb 16 '12 at 16:16

Just ending the command line with & will not completely detach the process, it will just run it in the background. (With zsh you can use &! to actually detach it, otherwise you have do disown it later).

When a process runs in the background, it won't receive input from its controlling terminal anymore. But you can send it back into the foreground with fg and then it will read input again.

Otherwise, it's not possible to externally change its filedescriptors (including stdin) or to reattach a lost controlling terminal… unless you use debugging tools (see Ansgar's answer, or have a look at the retty command).

share|improve this answer
And there is a related question here: unix.stackexchange.com/q/17648/9426 – Stéphane Gimenez Feb 16 '12 at 16:04
@Rogach stated "That terminal is now long closed". – andcoz Feb 16 '12 at 18:35
@andcoz: Yes but he's been lucky that the program has not been SIGHUPed. I was suggesting a safer method. – Stéphane Gimenez Feb 17 '12 at 11:25
here, disown only really works if I first redirect stdout like with >>/dev/stderr, otherwise, when I close the terminal, the "disowned" process will end too.. I never really understood this tho.. – Aquarius Power Nov 20 '15 at 5:08

Your Answer


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.