Server script without built-in sockets

[Craig White]

On Tue, 2007-10-23 at 16:40 -0700, Kurt Granroth wrote:
> 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 :-)
----
Thanks for the credit, it's not often I get to do the heavy lifting.

;-)

To quote PeeWee... I meant to say that.

I'm gonna save the e-mail in the hope that someday I may actually
understand what you are doing and possibly, though doubtful, I may
actually have use for this info.

Craig