Bash script via inetd = no joy

Discussion in 'Linux Networking' started by tylernt, Aug 29, 2003.

  1. tylernt

    tylernt Guest

    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"
     
    tylernt, Aug 29, 2003
    #1
    1. Advertisements

  2. 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.
    You could pipe all the output through a sed command that adds \r at the end
    of each line.
     
    Barry Margolin, Aug 29, 2003
    #2
    1. Advertisements

  3. 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
     
    laura fairhead, Aug 29, 2003
    #3
  4. tylernt

    Ian Fitchet Guest

    You're right, of course, Barry.

    Foolish boy, Pike!

    Cheers,

    Ian
     
    Ian Fitchet, Aug 29, 2003
    #4
  5. 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.

    byefornow
    l
     
    laura fairhead, Aug 29, 2003
    #5
  6. 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, Aug 29, 2003
    #6
  7. tylernt

    /dev/rob0 Guest

    Why not just "echo -e '\r'" after each line?
     
    /dev/rob0, Aug 30, 2003
    #7
  8. tylernt

    Ian Fitchet Guest

    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
     
    Ian Fitchet, Aug 30, 2003
    #8
  9. tylernt

    Dan Mercer Guest

    : 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



    :
    : 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"
     
    Dan Mercer, Aug 30, 2003
    #9
  10. <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
     
    Chris Thompson, Sep 5, 2003
    #10
  11. IIRC, BSD stty originally used stdout, AT&T's worked on stdin.

    In any case, when the process is invoked by inetd, *all* the stdXXX
    descriptors are connected to the socket, there's no terminal on any of
    them.
     
    Barry Margolin, Sep 5, 2003
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.