Kurt Granroth wrote:
> Here's an esoteric question for those of you wanting a challenge. How
> can I turn an arbitrary non-networked bash script into a server?
[snip]
Found it!
$ mkfifo sock
$ netcat -lp 16789 < <(script.sh <sock 2>&1) >sock
Craig's suggestion on 'expect' actually put me on the right track. I
got to thinking that I could start up netcat in a background process and
somehow communicate with it. I couldn't think of how to do it until
last night when I was drifting off to sleep, a thought just popped into
my brain "named pipes"... and then I went to sleep.
When I woke up this morning, I puzzled on what that cryptic "named
pipes" could mean when it hit me that I could redirect stdin and stdout
from netcat using a named pipe (fifo) and use that to communicate with
the controlling process!
Sweet.
It took me a little longer than I'd like to find the final version of
that line. The problem that eluded me was how to get *input* from the
fifo. A little process substitution was just was the doctor ordered.
If that line looks like random characters to you, here's an explanation.
$ mkfifo sock
This creates a "named pipe" which is a special file that can be used to
communicate between processes. You can experiment with this yourself
thusly:
1. In one window, type "mkfifo fifo; cat < fifo"
2. In another window, type "echo 'Hello, world' > fifo"
3. Notice that it prints out in the 'cat' window
$ netcat -lp 16789
Starts up netcat in listening mode on port 16789
$ netcat -lp 16789 >sock
Redirects all output received by netcat to the named pipe 'sock'. That
means that anything that is doing a 'read' on 'sock' will get whatever
netcat receives
$ ... <(script.sh <sock 2>&1) ...
A little black-magic. This opens up 'script.sh' in a sub-process and
gives it the 'sock' fifo to use as stdin. Handily, my script does a
'read' on stdin so it hangs until there is some data on fifo. The final
2>&1 redirects stderr to stdout so that everything is going out on one f
file descriptor
Putting it altogether:
$ netcat -lp 16789 < <(script.sh <sock 2>&1) >sock
script.sh is started up first in a sub-process and waits while reading
'sock'. When netcat receives some data over the network, it passes it
off to 'sock'. script.sh now reads in the data as if it was normal
stdin and process it. It's output is redirected to stdout which is now
stdin for netcat. netcat pushes the output as its response over the
network.
Simple :-)
Kurt
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)
