yeah but it might have to be a one liner, which is fine, pipes are so. I don't know whether you can tell nc and pipe to an already running instance by pid. you can nc to an ip and pipe it to an nc that is listening and pipe that to an nc that is listening etc and pipe that to nc to an ip.

I changed the title because what you mention sounds more like I/O redirection rather than the use of a pipe (which only deals with moving the output of one process to the input of another).

@Breakthrough how does that differ from pipes? as he's talking about IO redirection and not talking about files, then how does it differ from piping?

@barlop I/O redirection (< or >) is significantly different from piping (|), although you can sometimes achieve an equivalent operation with a mix of both. Again though, with I/O redirection, you can change the location of both streams; piping just redirects the standard output of one process to the standard input of another.

@Breakthrough see what I asked you though. > and < is of course different from piping because < and > use files. But he's not talking of files. I asked you "how does that[IO redirection] differ from pipes? as he's talking about IO redirection and not talking about files, then how does it differ from piping? "

@barlop see Scott's answer below. Piping only deals with the standard output of the spawned process, and not the standard input. You need to somehow redirect it from another asynchronous process (like sockets). However, I do see what you meant now. So yes, I/O redirection even without files is not equivalent to piping (as per the semantics of what a pipe does).

i'm aware of scott's answer with nc -l -p i've done it before though not used -e. As for redirecting stdin..

i'm not sure what would be meant by you perhaps suggesting IO redirection can involve redirecting stdin, Like, monitoring one processes std'in of process p1, and copying it to another process before it reaches p1? scott's answer uses pipes though I see he uses < and > too. I guess i'll look into that mkfifo and < and > to get a better grasp of what's happening. As I don't yet see what that can do that the regular pipes can't.

I know > does stdout and when i've used < i've found that also redirects stdout program1 < program2 redirects program2's stdout to program1's stdin. and have been able to use | as an alternative. program2 | program1. I don't know which process you are calling the spawned one? i'd have thought that the shell spawns both of them.

program1 < program2 redirects program2's stdout to program1's stdin is false.

A shell would assume program2 is a file, and would open the file as a stream representing program1's stdin.

It's equivalent to doing echo program2 | program1, but it is not the same thing as a pipe (as you would require echo or cat to do it).

mkfifo creates special files which you can use for asynchronous stream redirection.

I think Wikipedia explains this better than I can: en.wikipedia.org/wiki/Redirection_%28computing%29#Piping

Also, see the manpage for mkfifo: linux.die.net/man/3/mkfifo

> A FIFO special file is similar to a pipe, except that it is created in a different way. [...] Once you have created a FIFO special file in this way, any process can open it for reading or writing, in the same way as an ordinary file. However, it has to be open at both ends simultaneously before you can proceed to do any input or output operations on it. Opening a FIFO for reading normally blocks until some other process opens the same FIFO for writing, *and vice versa.*