Skip to main content
added 1 character in body
Source Link
heemayl
  • 58.1k
  • 9
  • 129
  • 144

I guess that is impossible with a "real" pipeline.

Instead you can use a FIFO (named pipe, see man mkfifo) or (more elegant but more complicated) a Unix socket (AF_UNIX).

./background-proc </path/to/fifo &
cat >/path/to/fifo
# typing commands into cat

I am not a developer so my only relation to sockets is socat. But that may help as a start.

You need a "server" which communicates with your program. Such a pipeline would be started in the background:

socat UNIX-LISTEN:/tmp/sockettest,fork STDOUT | sed 's/./&_/g'

The sed is just for testing.

Then you start one or more

socat STDIN UNIX-CONNECT:/tmp/sockettest

If you have a program which generates the commands for your background program then you would use a pipeline here, too:

cmd_prog | ocatsocat STDIN UNIX-CONNECT:/tmp/sockettest

The advantage in comparison with a FIFO is that (with the option fork on the server side) you can disconnect and reconnect the client. Using a FIFO you would need tricks for keeping the receiving side running:

while true; do cat /path/to/fifo; done | background_prog

I guess that is impossible with a "real" pipeline.

Instead you can use a FIFO (named pipe, see man mkfifo) or (more elegant but more complicated) a Unix socket (AF_UNIX).

./background-proc </path/to/fifo &
cat >/path/to/fifo
# typing commands into cat

I am not a developer so my only relation to sockets is socat. But that may help as a start.

You need a "server" which communicates with your program. Such a pipeline would be started in the background:

socat UNIX-LISTEN:/tmp/sockettest,fork STDOUT | sed 's/./&_/g'

The sed is just for testing.

Then you start one or more

socat STDIN UNIX-CONNECT:/tmp/sockettest

If you have a program which generates the commands for your background program then you would use a pipeline here, too:

cmd_prog | ocat STDIN UNIX-CONNECT:/tmp/sockettest

The advantage in comparison with a FIFO is that (with the option fork on the server side) you can disconnect and reconnect the client. Using a FIFO you would need tricks for keeping the receiving side running:

while true; do cat /path/to/fifo; done | background_prog

I guess that is impossible with a "real" pipeline.

Instead you can use a FIFO (named pipe, see man mkfifo) or (more elegant but more complicated) a Unix socket (AF_UNIX).

./background-proc </path/to/fifo &
cat >/path/to/fifo
# typing commands into cat

I am not a developer so my only relation to sockets is socat. But that may help as a start.

You need a "server" which communicates with your program. Such a pipeline would be started in the background:

socat UNIX-LISTEN:/tmp/sockettest,fork STDOUT | sed 's/./&_/g'

The sed is just for testing.

Then you start one or more

socat STDIN UNIX-CONNECT:/tmp/sockettest

If you have a program which generates the commands for your background program then you would use a pipeline here, too:

cmd_prog | socat STDIN UNIX-CONNECT:/tmp/sockettest

The advantage in comparison with a FIFO is that (with the option fork on the server side) you can disconnect and reconnect the client. Using a FIFO you would need tricks for keeping the receiving side running:

while true; do cat /path/to/fifo; done | background_prog
added 852 characters in body
Source Link
Hauke Laging
  • 94.8k
  • 21
  • 132
  • 185

I guess that is impossible with a "real" pipeline.

Instead you can use a FIFO (named pipe, see man mkfifo) or (more elegant but more complicated) a Unix socket (AF_UNIX).

./background-proc </path/to/fifo &
cat >/path/to/fifo
# typing commands into cat

I am not a developer so my only relation to sockets is socat. But that may help as a start.

You need a "server" which communicates with your program. Such a pipeline would be started in the background:

socat UNIX-LISTEN:/tmp/sockettest,fork STDOUT | sed 's/./&_/g'

The sed is just for testing.

Then you start one or more

socat STDIN UNIX-CONNECT:/tmp/sockettest

If you have a program which generates the commands for your background program then you would use a pipeline here, too:

cmd_prog | ocat STDIN UNIX-CONNECT:/tmp/sockettest

The advantage in comparison with a FIFO is that (with the option fork on the server side) you can disconnect and reconnect the client. Using a FIFO you would need tricks for keeping the receiving side running:

while true; do cat /path/to/fifo; done | background_prog

I guess that is impossible with a "real" pipeline.

Instead you can use a FIFO (named pipe, see man mkfifo) or (more elegant but more complicated) a Unix socket (AF_UNIX).

./background-proc </path/to/fifo &
cat >/path/to/fifo
# typing commands into cat

I guess that is impossible with a "real" pipeline.

Instead you can use a FIFO (named pipe, see man mkfifo) or (more elegant but more complicated) a Unix socket (AF_UNIX).

./background-proc </path/to/fifo &
cat >/path/to/fifo
# typing commands into cat

I am not a developer so my only relation to sockets is socat. But that may help as a start.

You need a "server" which communicates with your program. Such a pipeline would be started in the background:

socat UNIX-LISTEN:/tmp/sockettest,fork STDOUT | sed 's/./&_/g'

The sed is just for testing.

Then you start one or more

socat STDIN UNIX-CONNECT:/tmp/sockettest

If you have a program which generates the commands for your background program then you would use a pipeline here, too:

cmd_prog | ocat STDIN UNIX-CONNECT:/tmp/sockettest

The advantage in comparison with a FIFO is that (with the option fork on the server side) you can disconnect and reconnect the client. Using a FIFO you would need tricks for keeping the receiving side running:

while true; do cat /path/to/fifo; done | background_prog
Source Link
Hauke Laging
  • 94.8k
  • 21
  • 132
  • 185

I guess that is impossible with a "real" pipeline.

Instead you can use a FIFO (named pipe, see man mkfifo) or (more elegant but more complicated) a Unix socket (AF_UNIX).

./background-proc </path/to/fifo &
cat >/path/to/fifo
# typing commands into cat