Network redirection in bash

[Todd A. Jacobs]

I'm trying something a little weird, and am not having much success
with my shell redirection to a network port. I'm trying to send an MS
Word file to antiword running out of inetd. Here's what I have on the
client side:

exec 4<> /dev/tcp/127.0.0.1/2100
cat /tmp/foo.doc >&4
cat <&4

This seems like it should work, but I never get any results back from
antiword. Basically, it just waits until the service times out.

I'm hoping I'm just doing something wrong with my shell redirection
here. Thoughts?

[Todd A. Jacobs]

On Apr 10, 4:26 am, "Todd A. Jacobs" <nos...@codegnome.org> wrote:
> I'm hoping I'm just doing something wrong with my shell redirection
> here. Thoughts?

Just in case I've done something stupid in xinetd, I thought I'd post
my configuration for that, too.

service antiword
{
disable = no
type = UNLISTED
id = antiword
flags += NODELAY IPv4
socket_type = stream
protocol = tcp
user = nobody
group = nogroup
wait = no
nice = 10
env += ANTIWORDHOME=/usr/share/antiword
port = 2100
server = /usr/bin/antiword
server_args = -
log_type = FILE /tmp/antiword.log
log_on_success += EXIT DURATION
log_on_failure += ATTEMPT
banner = /etc/motd
only_from = 127.0.0.1
}

[Todd A. Jacobs]

On Apr 10, 4:26 am, "Todd A. Jacobs" <nos...@codegnome.org> wrote:

>     exec 4<> /dev/tcp/127.0.0.1/2100
>     cat /tmp/foo.doc >&4
>     cat <&4

As a sanity check, I tried this successfully:

# XTerm 1
nc -l 2100 | antiword - | nc -l 2101

# XTerm 2
# send file to antiword
nc localhost 2100 < /tmp/foo.doc
# read antiword's results
nc localhost 2101

Since that works, I'm really pretty sure that I'm just failing to hook
up standard output or standard input correctly somewhere.

[Stephane CHAZELAS]

2011-04-10, 04:26(-07), Todd A. Jacobs:

It won't work for the same reason as

cat foo.doc /dev/tty | antiword -

won't output anything until you press Ctrl-D.

You'd need to shutdown the socket for sending first so that
antiword sees the end of file. Unfortunately, I don't think bash
allows you do close the sending and receiving side separately.
zsh's ztcp can't either as far as I can tell. You'd need to find
a way to tell antiword about the end of input another way.

You could for instance change it to accept uuencoded files and
handle the input with a wrapper script that does:

#! /usr/bin/awk -f
BEGIN{cmd="uudecode -o - | antiword -"}
{print | cmd}
/^end/{close(cmd)}

(untested).

--
Stephane