Using listening sockets from a shell script
Tom Anderson
I'd like to have a shell script which accepted connections over the
network and responded to messages sent over sockets. I can do this with
good old inetd, but i was wondering if there were other ways to do it. Is
there a way to do socket/bind/listen/accept directly from bash? Or any
other construct (unix domain socket trickery etc) that would let a script
work with sockets accepted on its behalf by some binary process?
tom
--
1 pWN 3v3Ry+h1n G!!!1
Robert Billing
Anderson had written:
It might be easier to do this from Perl or TCL than from bash.
--
I am Robert Billing, Christian, author, inventor, traveller, cook and
animal lover. "It burned me from within. It quickened; I was with book
as a woman is with child."
Quality e-books for portable readers: http://www.alex-library.com
Martin Gregorie
Have you looked at nc / netcat?
However, I'd go with xinetd for the sheer simplicity of doing it that way.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Mark Hobley
> Is there a way to do socket/bind/listen/accept directly from bash?
Yeah. The bash shell supports socket programming via the /dev/tcp interface.
I was looking to implement /dev/tcp as a general system device (rather than
as a bashism).
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Tom Anderson
> Tom Anderson <tw...@urchin.earth.li> wrote:
>> Is there a way to do socket/bind/listen/accept directly from bash?
>
> Yeah. The bash shell supports socket programming via the /dev/tcp
> interface. I was looking to implement /dev/tcp as a general system
> device (rather than as a bashism).
Eeeeenteresting. Can you do listening (server-side) sockets with /dev/tcp?
All the descriptions i can find are about client-side sockets.
tom
--
The cause? Thatcher again. Not for any specific reasons but she's always
the root of every problem in Britain today. -- Mike
Tom Anderson
> As the bottle floated ashore we opened it and found the message that Tom
> Anderson had written:
>
>> I'd like to have a shell script which accepted connections over the
>> network and responded to messages sent over sockets. I can do this with
>> good old inetd, but i was wondering if there were other ways to do it.
>> Is there a way to do socket/bind/listen/accept directly from bash? Or
>> any other construct (unix domain socket trickery etc) that would let a
>> script work with sockets accepted on its behalf by some binary process?
>
> It might be easier to do this from Perl or TCL than from bash.
Oh, undoubtedly. And even easier from python. But i was specifically
wondering about doing it from bash - i'm really just interested in the
limits of what you can do in shell script. My medium-term goal here is to
write a noddy HTTP server in bash, for the amusement of my colleagues.
Robert Billing
Anderson had written:
> On Thu, 18 Mar 2010, Robert Billing wrote:
>
>> As the bottle floated ashore we opened it and found the message that
>> Tom Anderson had written:
>>
>>> I'd like to have a shell script which accepted connections over the
>>> network and responded to messages sent over sockets. I can do this
>>> with good old inetd, but i was wondering if there were other ways to
>>> do it. Is there a way to do socket/bind/listen/accept directly from
>>> bash? Or any other construct (unix domain socket trickery etc) that
>>> would let a script work with sockets accepted on its behalf by some
>>> binary process?
>>
>> It might be easier to do this from Perl or TCL than from bash.
>
> Oh, undoubtedly. And even easier from python. But i was specifically
> wondering about doing it from bash - i'm really just interested in the
> limits of what you can do in shell script. My medium-term goal here is
> to write a noddy HTTP server in bash, for the amusement of my
> colleagues.
>
> tom
Actually you can write cgi scripts in bash, using Apache. There's an
example in my <blatant_plug> book </blatant_plug> which displays the time.
#!/bin/bash
# CGI compatible real time clock
echo "Content-type: text/html"
echo
echo "<HTML>"
echo "<head>"
echo "<title>CGI Clock</title>"
echo "</head>"
echo "<body>"
echo "Time now:<br>"
date
echo "</body>"
echo "</HTML>"
Gordon Henderson
NAME
nc - TCP/IP swiss army knife
SYNOPSIS
nc [-options] hostname port[s] [ports] ...
nc -l -p port [-options] [hostname] [port]
DESCRIPTION
netcat is a simple unix utility which reads and writes data across net-
work connections, using TCP or UDP protocol. It is designed to be a
reliable "back-end" tool that can be used directly or easily driven by
other programs and scripts. At the same time, it is a feature-rich
network debugging and exploration tool, since it can create almost any
kind of connection you would need and has several interesting built-in
capabilities. Netcat, or "nc" as the actual program is named, should
have been supplied long ago as another one of those cryptic but stan-
dard Unix tools.
etc.
Gordon
Tom Anderson
> In article <alpine.DEB.1.10.1...@urchin.earth.li>,
> Tom Anderson <tw...@urchin.earth.li> wrote:
>
>> I'd like to have a shell script which accepted connections over the
>> network and responded to messages sent over sockets. I can do this with
>> good old inetd, but i was wondering if there were other ways to do it. Is
>> there a way to do socket/bind/listen/accept directly from bash? Or any
>> other construct (unix domain socket trickery etc) that would let a script
>> work with sockets accepted on its behalf by some binary process?
>
> NAME
> nc - TCP/IP swiss army knife
>
> SYNOPSIS
> nc [-options] hostname port[s] [ports] ...
> nc -l -p port [-options] [hostname] [port]
Aha, didn't think to check if netcat does listening sockets (which it
does) - thanks.
A possibly minor caveat is that you can't (that i can see) handle several
connections to a port at once, even using multiple processes. You can
accept one connection then exit, but you hold the listening socket until
you exit, so you can't have multiple processes doing that in parallel. You
can accept a series of connections, but not in parallel.
So, compared to inetd, there's less parallelism, but you can do the whole
thing from inside a single script. Interesting.
tom
--
I thought it would be fun if I could get the baby do do communism stuff
with me, but when I tried to get her attention she crawled over to the
VCR and put a breadstick into it. That's not communism! That's anarchy! --
Philippe
Nix
> A possibly minor caveat is that you can't (that i can see) handle
> several connections to a port at once, even using multiple
> processes. You can accept one connection then exit, but you hold the
> listening socket until you exit, so you can't have multiple processes
> doing that in parallel. You can accept a series of connections, but
> not in parallel.
You want socat(1), which can do anything, specifically this (you want
the 'fork' option to TCP-LISTEN.)
Downside: enough features to drive even an Emacs user mad.
Tom Anderson
> On 19 Mar 2010, Tom Anderson said:
>
>> A possibly minor caveat is that you can't (that i can see) handle
>> several connections to a port at once, even using multiple processes.
>> You can accept one connection then exit, but you hold the listening
>> socket until you exit, so you can't have multiple processes doing that
>> in parallel. You can accept a series of connections, but not in
>> parallel.
>
> You want socat(1), which can do anything,
Okay, socat is new to me, and is very cool.
> specifically this (you want the 'fork' option to TCP-LISTEN.)
I'm still trying to figure out how i could use that and then actually deal
with the multiple connections; i can make the second stream be an EXEC of
a handler script (thus essentially using socat like a mini-inetd), or i
could create a named pipe and then work with that in the main script, or
fork that script to work with it, or i could do something similar but with
a listening unix-domain socket, which i could then connect to in the main
script or a child, or i could get socat to talk to my standard in and out,
then use bash's file descriptor operators to shuffle them off out of the
way and work with them (not sure about this one).
At this point, the choice is probably dictated by the process model i
want, so the ball is back in my court!
> Downside: enough features to drive even an Emacs user mad.
THE POWER! THE POWER!!
tom
--
Change happens with ball-flattening speed. -- Thomas Edison
Tom Anderson
> Tom Anderson <tw...@urchin.earth.li> wrote:
>
>> Oh, undoubtedly. And even easier from python. But i was specifically
>> wondering about doing it from bash - i'm really just interested in the
>> limits of what you can do in shell script. My medium-term goal here is
>> to write a noddy HTTP server in bash, for the amusement of my
>> colleagues.
>
> If you want to see the limits of shell script being tested, have a look
> at bashreduce: http://blog.last.fm/2009/04/06/mapreduce-bash-script
Nice!
tom
--
Astronomy's a fascinating subject. You look up ... and it's there. --
Patrick Moore