Prev: Getting WinXP off a FakeRaid setup
Next: Any open source console mode accounts packages available for Linux?
From: Tom Anderson on 18 Mar 2010 21:47
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

--
The cause? Thatcher again. Not for any specific reasons but she's always
the root of every problem in Britain today. -- Mike
From: Robert Billing on 19 Mar 2010 04:20
As the bottle floated ashore we opened it and found the message that Tom
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>"


--
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
From: Gordon Henderson on 19 Mar 2010 04:32
In article <alpine.DEB.1.10.1003182203130.13439(a)urchin.earth.li>,
Tom Anderson <twic(a)urchin.earth.li> wrote:
>Evening all,
>
>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]

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
From: Tom Anderson on 19 Mar 2010 12:26
On Fri, 19 Mar 2010, Gordon Henderson wrote:

> In article <alpine.DEB.1.10.1003182203130.13439(a)urchin.earth.li>,
> Tom Anderson <twic(a)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
From: Nix on 19 Mar 2010 22:43
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, specifically this (you want
the 'fork' option to TCP-LISTEN.)

Downside: enough features to drive even an Emacs user mad.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Getting WinXP off a FakeRaid setup
Next: Any open source console mode accounts packages available for Linux?