Bash script via inetd = no joy

Hello,

I wrote a Bash script in Linux using 'read' and 'echo'. The script
works just fine from the console.

However, when I put it in services and inetd.conf and then telnet in
to run it, I get a stairstep effect: after the script 'echo'es
something and then tries to 'read' something, the cursor is placed
below the last character printed from the 'echo' rather than in the
leftmost column. Like LF was issued but not CR. This occurs using both
the Win2k telnet client and from the Linux telnet client.

Also. If I 'echo' back the variable that I just 'read', it shows what
I typed in, but none of my 'if' statement logic recognizes the string
(perhaps because there is a hidden CR and/or LF attached?).

It seems to be a CRLF thing... any idea how to run a Bash script that
uses 'echo' and 'read' via inetd? Or are there equivalent Bash
commands that are more CRLF friendly when run through inetd? Or can I
append some CR/LF codes to my 'echo'es and strip extra CR/LFs from my
'read's somehow?

And yes, I know this is a huge security hole but it's in a protected
test environemnt.

Please help... Thanks in advance!! Here is the script:

#!/bin/bash
echo "Greetings"
read myinput
until [ "$myinput" = "quit" ]
do
if [ "$myinput" = "data" ]; then
echo "Enter your data"
read mydata
until [ "$mydata" = "stop" ]
do
echo $mydata >> ~/output.txt
read mydata
done
echo "Data received"
else
echo "Unknown command"
fi
read myinput
done
echo "Goodbye"

In article <(E-Mail Removed) >,
tylernt <(E-Mail Removed)> wrote:
>Hello,
>
>I wrote a Bash script in Linux using 'read' and 'echo'. The script
>works just fine from the console.
>
>However, when I put it in services and inetd.conf and then telnet in
>to run it, I get a stairstep effect: after the script 'echo'es
>something and then tries to 'read' something, the cursor is placed
>below the last character printed from the 'echo' rather than in the
>leftmost column. Like LF was issued but not CR. This occurs using both
>the Win2k telnet client and from the Linux telnet client.

In the TELNET protocol, newline is represented using the two-byte sequence
CR LF. But your script is just sending LF, because that's what Unix uses
to represent newline. The telnet client is just sending what it received
to the terminal.

>It seems to be a CRLF thing... any idea how to run a Bash script that
>uses 'echo' and 'read' via inetd? Or are there equivalent Bash
>commands that are more CRLF friendly when run through inetd? Or can I
>append some CR/LF codes to my 'echo'es and strip extra CR/LFs from my
>'read's somehow?

You could pipe all the output through a sed command that adds \r at the end
of each line.

--
Barry Margolin, (E-Mail Removed)
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

On 29 Aug 2003 11:10:53 -0700, (E-Mail Removed) (tylernt) wrote:

>Hello,
>
>I wrote a Bash script in Linux using 'read' and 'echo'. The script
>works just fine from the console.
>
>However, when I put it in services and inetd.conf and then telnet in
>to run it, I get a stairstep effect: after the script 'echo'es
>something and then tries to 'read' something, the cursor is placed
>below the last character printed from the 'echo' rather than in the
>leftmost column. Like LF was issued but not CR. This occurs using both
>the Win2k telnet client and from the Linux telnet client.
>
>Also. If I 'echo' back the variable that I just 'read', it shows what
>I typed in, but none of my 'if' statement logic recognizes the string
>(perhaps because there is a hidden CR and/or LF attached?).
>
>It seems to be a CRLF thing... any idea how to run a Bash script that
>uses 'echo' and 'read' via inetd? Or are there equivalent Bash
>commands that are more CRLF friendly when run through inetd? Or can I
>append some CR/LF codes to my 'echo'es and strip extra CR/LFs from my
>'read's somehow?

I would fiddle with the terminal settings, for example when you
do a 'stty -a' is the 'onlcr' setting enabled ?

If not then a simple "stty onlcr" might be what you need.

You can find out about what is going on with the input and
check for a hidden CR with something like;

echo "$myinput" |od -txCa

If there is a problem on the input as well you may want
to do another 'stty' this time adjusting an input setting.


byefrom
l


--
echo (E-Mail Removed) |sed 's/\(.\)\(.\)/\2\1/g'

Barry Margolin <(E-Mail Removed)> writes:

> Stty only works if stdout is a terminal. When his script is run from
> inetd, stdout is a network socket.

You're right, of course, Barry.

Foolish boy, Pike!

Cheers,

Ian

On Fri, 29 Aug 2003 19:44:00 GMT, Barry Margolin <(E-Mail Removed)> wrote:

>In article <(E-Mail Removed)>,
>Ian Fitchet <(E-Mail Removed)> wrote:
>>Barry Margolin <(E-Mail Removed)> writes:
>>
>>> You could pipe all the output through a sed command that adds \r at the end
>>> of each line.
>>
>> You could throw a quick
>>
>>stty onlcr
>>
>> into the top of your script.
>
>Stty only works if stdout is a terminal. When his script is run from
>inetd, stdout is a network socket.

I don't think this is true although to be sure I'm not up on all off the
intricacies of terminals and NVT's in UNIX yet (interesting subject ,
but the fact is that stdout is a pty (psuedo-terminal device ) when I use
telnet- as such why can't that (terminal) device support the ioctl
interface? Just testing using 'putty' on windows to connect to a linux box
(telnetd) I find that setting onlcr on/off has the desired effect.

>
>--
>Barry Margolin, (E-Mail Removed)
>Level(3), Woburn, MA
>*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
>Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


byefornow
l


--
echo (E-Mail Removed) |sed 's/\(.\)\(.\)/\2\1/g'

In article <(E-Mail Removed)>,
laura fairhead <(E-Mail Removed)> wrote:
>On Fri, 29 Aug 2003 19:44:00 GMT, Barry Margolin
><(E-Mail Removed)> wrote:
>>Stty only works if stdout is a terminal. When his script is run from
>>inetd, stdout is a network socket.
>
>I don't think this is true although to be sure I'm not up on all off the
>intricacies of terminals and NVT's in UNIX yet (interesting subject ,
>but the fact is that stdout is a pty (psuedo-terminal device ) when I use
>telnet- as such why can't that (terminal) device support the ioctl
>interface? Just testing using 'putty' on windows to connect to a linux box
>(telnetd) I find that setting onlcr on/off has the desired effect.

When you do a normal telnet, it's telnetd, not inetd, that sets up the pty.
But if you run an ordinary program (regardless of whether it's a script or
binary) via inetd, its stdin/stdout/stderr will be connected directly to
the socket. There's no pty unless the program that inetd invokes
explicitly sets it up.

It would certainly be nice if there were an easy way to insert an NVT
filter in the data path. But it's not AFAIK. So it's the responsibility
of the server application to ensure that it performs appropriate input and
output translation.

--
Barry Margolin, (E-Mail Removed)
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

In article <(E-Mail Removed)>, laura fairhead wrote:
> Well I think your sed filter method is probably the best idea then

Why not just "echo -e '\r'" after each line?
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

Barry Margolin <(E-Mail Removed)> writes:

> You could pipe all the output through a sed command that adds \r at the end
> of each line.

How do people feel about this?

#! /bin/bash

exec > >(sed -e 's/$/FOO/')

echo hello
echo hello


Where I guess `FOO' is inappropriate in this case.

Cheers,

Ian

"tylernt" <(E-Mail Removed)> wrote in message news:(E-Mail Removed) om...
: Hello,
:
: I wrote a Bash script in Linux using 'read' and 'echo'. The script
: works just fine from the console.
:
: However, when I put it in services and inetd.conf and then telnet in
: to run it, I get a stairstep effect: after the script 'echo'es
: something and then tries to 'read' something, the cursor is placed
: below the last character printed from the 'echo' rather than in the
: leftmost column. Like LF was issued but not CR. This occurs using both
: the Win2k telnet client and from the Linux telnet client.

The Win2k telnet client is a POS. You need to get a real telnet client,
like the Cygwin client. That will allow you to set the modes by which
telnet handles carriage returns.

set crlf on # send cr as cr-lf
set crmod on # handle received cr-lf sequence properly

You can also add cr to the IFS string on a read so it is ignored:
Assuming your bash is really bash2 (bash1 is obsolescent):

cr=$'\r'

IFS="${IFS}${cr}" read mydata

Your linux telnet should already have the same capabilities as the cygwin
telnet.

Dan Mercer
(E-Mail Removed)


:
: Also. If I 'echo' back the variable that I just 'read', it shows what
: I typed in, but none of my 'if' statement logic recognizes the string
: (perhaps because there is a hidden CR and/or LF attached?).
:
: It seems to be a CRLF thing... any idea how to run a Bash script that
: uses 'echo' and 'read' via inetd? Or are there equivalent Bash
: commands that are more CRLF friendly when run through inetd? Or can I
: append some CR/LF codes to my 'echo'es and strip extra CR/LFs from my
: 'read's somehow?
:
: And yes, I know this is a huge security hole but it's in a protected
: test environemnt.
:
: Please help... Thanks in advance!! Here is the script:
:
: #!/bin/bash
: echo "Greetings"
: read myinput
: until [ "$myinput" = "quit" ]
: do
: if [ "$myinput" = "data" ]; then
: echo "Enter your data"
: read mydata
: until [ "$mydata" = "stop" ]
: do
: echo $mydata >> ~/output.txt
: read mydata
: done
: echo "Data received"
: else
: echo "Unknown command"
: fi
: read myinput
: done
: echo "Goodbye"

In article <42O3b.503$(E-Mail Removed)>,
Barry Margolin <(E-Mail Removed)> wrote:
[...]
>Stty only works if stdout is a terminal. When his script is run from
>inetd, stdout is a network socket.

<nitpick> stdin, not stdout </nitpick>

At least, in the implementations of stty(1) I am familiar with.

Chris Thompson
Email: cet1 [at] cam.ac.uk