How to read inputs from another terminal? - Unix

This is a discussion on How to read inputs from another terminal? - Unix ; Hi, I want to write a program which run on terminal A but get inputs and write outputs from/to another terminal B. Two terminals will running bash shell. I wrote some test code, but have not managed to make it ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: How to read inputs from another terminal?

  1. How to read inputs from another terminal?

    Hi,

    I want to write a program which run on terminal A but get inputs and
    write outputs from/to another terminal B. Two terminals will running
    bash shell. I wrote some test code, but have not managed to make it
    work.

    --- rwtty.c ----
    #include
    #include
    #include
    #include
    #include

    int main( const int argc, char* argv[] )
    {
    char term_name[ 64 ];
    sprintf( term_name, "/dev/%s", argv[ 1 ] );

    int term = open( term_name, O_RDWR );
    if ( term <= 0 )
    return 1;

    const char* hello_str = "Hello, world!\n";
    write( term, hello_str, strlen( hello_str ));

    char buff[ 80 ];
    ssize_t len;
    while ( len = read( term, buff, sizeof( buff )))
    write( term, buff, len );

    return 0;
    }
    ----------------

    I lauched this program on terminal tty0, but have it read/write from/
    to tty1,
    $ rwtty tty1

    Then, on the tty1, I saw the "Hello, world!" printed on the shell
    prompt, it's good. But when I inputed anything on the tty1 hoping it
    can be received by the program on tty0, the result was nothing.
    Rather than my expected, the `bash' on the tty1 got the input, and it,
    of course, just said "command not found".

    Is there a way bypassing the bash?

    -
    woody

  2. Re: How to read inputs from another terminal?

    >I want to write a program which run on terminal A but get inputs and
    >write outputs from/to another terminal B. Two terminals will running
    >bash shell. I wrote some test code, but have not managed to make it
    >work.


    Open the other terminal, possibly set serial line parameters like
    baud rate and echo and CR/LF translation, then read or write from
    it. However, one thing you need to deal with is getting anything
    else reading the other terminal to stop doing that. There's no way
    to type something at a particular read request if there's more than
    one in progress. This is sometimes done by turning off "getty" on
    the particular terminal involved, so no one can log in on it. It's
    often appropriate for modems or printers.

    Some systems have "virtual terminals" on the console, and you can
    switch between different virtual terminals using keystroke combinations.
    In this case, clean off the read requests on one particular virtual
    terminal (including turning off getty on that virtual terminal),
    and you can use that. Switch to the virtual terminal, type something,
    and it will go to the only read request on it.



  3. Re: How to read inputs from another terminal?

    Steven Woody writes:
    >Hi,
    >
    >I want to write a program which run on terminal A but get inputs and
    >write outputs from/to another terminal B. Two terminals will running
    >bash shell. I wrote some test code, but have not managed to make it
    >work.


    1) What operating environment are you using?
    2) What type of "terminal"?
    - Virtual Terminal?
    - Pseudo Terminal?
    - Serial Terminal?
    - Graphical (e.g. xterm/gnome_terminal, et. al.)

    If Virtual Terminal (as your example appears to use), and you're
    on a linux-based operating environment, type:

    bash$ man openvt

    scott

  4. Re: How to read inputs from another terminal?

    Steven Woody wrote:
    > I want to write a program which run on terminal A but get inputs and
    > write outputs from/to another terminal B. Two terminals will running
    > bash shell. I wrote some test code, but have not managed to make it
    > work.



    > Then, on the tty1, I saw the "Hello, world!" printed on the shell
    > prompt, it's good. But when I inputed anything on the tty1 hoping it
    > can be received by the program on tty0, the result was nothing.
    > Rather than my expected, the `bash' on the tty1 got the input, and it,
    > of course, just said "command not found".


    What's happening is that both bash and your program now have the same
    file (the terminal) open, and they are both blocked on a read(). When
    data becomes available, the kernel gives it to an arbitrary one of the
    two. Think of this as a producer-consumer problem. You have a queue
    with one producer (the end user) and two consumers. The kernel is
    allowing either one to consume items from the queue, and neither can
    control what the other gets.

    In order to stop this, you have to tell the shell to stop trying to
    read from the terminal. One way is to type something like this at the
    bash prompt:

    exec < /dev/null ; sleep 60 ; exec < /dev/tty

    Personally, though, I think a cleaner design would be to either:
    (a) not have bash run at all, or
    (b) run a program within bash to do the communications.

    Others, I believe, have already explained how to do (a). To do
    (b), the simplest thing would be to have a pair of named pipes
    and then copy between those and the terminal. Your main program
    could then read/write to the pipes instead of to a foreign terminal.
    Another approach would be to use a TCP connection.

    - Logan

  5. Re: How to read inputs from another terminal?

    On Apr 9, 3:21 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
    > Steven Woody writes:
    > >Hi,

    >
    > >I want to write a program which run on terminal A but get inputs and
    > >write outputs from/to another terminal B. Two terminals will running
    > >bash shell. I wrote some test code, but have not managed to make it
    > >work.

    >
    > 1) What operating environment are you using?
    > 2) What type of "terminal"?
    > - Virtual Terminal?
    > - Pseudo Terminal?
    > - Serial Terminal?
    > - Graphical (e.g. xterm/gnome_terminal, et. al.)
    >
    > If Virtual Terminal (as your example appears to use), and you're
    > on a linux-based operating environment, type:
    >
    > bash$ man openvt
    >
    > scott


    Hi, Lurndal & Burditt

    The OS is Linux. The terminal A that is expected to input/output is a
    console ( a LCD connected to an ARM9 MCU ), the terminal B that I used
    to launch the program is a pseudo tty via a remote telnet or ssh
    connection. But when in development stage, the terminal A & B are
    both pseudo tty's via ssh connection.

    I like to provide any info if neccessary. Thanks.

    -
    woody

  6. Re: How to read inputs from another terminal?

    On Apr 9, 3:21 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
    > Steven Woody writes:
    > >Hi,

    >
    > >I want to write a program which run on terminal A but get inputs and
    > >write outputs from/to another terminal B. Two terminals will running
    > >bash shell. I wrote some test code, but have not managed to make it
    > >work.

    >
    > 1) What operating environment are you using?
    > 2) What type of "terminal"?
    > - Virtual Terminal?
    > - Pseudo Terminal?
    > - Serial Terminal?
    > - Graphical (e.g. xterm/gnome_terminal, et. al.)
    >
    > If Virtual Terminal (as your example appears to use), and you're
    > on a linux-based operating environment, type:
    >
    > bash$ man openvt
    >
    > scott


    Scott,

    Simply run `openvt cat -' on the /dev/pts/n just get an error "Couldnt
    get a file descriptor referring to the console".

    -
    woody

  7. Re: How to read inputs from another terminal?

    On Apr 9, 9:30 am, Logan Shaw wrote:
    > Steven Woody wrote:
    > > I want to write a program which run on terminal A but get inputs and
    > > write outputs from/to another terminal B. Two terminals will running
    > > bash shell. I wrote some test code, but have not managed to make it
    > > work.
    > > Then, on the tty1, I saw the "Hello, world!" printed on the shell
    > > prompt, it's good. But when I inputed anything on the tty1 hoping it
    > > can be received by the program on tty0, the result was nothing.
    > > Rather than my expected, the `bash' on the tty1 got the input, and it,
    > > of course, just said "command not found".

    >
    > What's happening is that both bash and your program now have the same
    > file (the terminal) open, and they are both blocked on a read(). When
    > data becomes available, the kernel gives it to an arbitrary one of the
    > two. Think of this as a producer-consumer problem. You have a queue
    > with one producer (the end user) and two consumers. The kernel is
    > allowing either one to consume items from the queue, and neither can
    > control what the other gets.
    >
    > In order to stop this, you have to tell the shell to stop trying to
    > read from the terminal. One way is to type something like this at the
    > bash prompt:
    >
    > exec < /dev/null ; sleep 60 ; exec < /dev/tty


    This is not pratical. The program under the question is actually an
    TUI ( text user interface ) running on an embedded system. When in
    case a system maintainer need to restart the TUI from a remote telnet
    pseudo tty, it usually means, he or she can not touch to the running
    system, so he can not execcute anything on it.

    >
    > Personally, though, I think a cleaner design would be to either:
    > (a) not have bash run at all, or


    I don't get the idea ... Would you explain?

    > (b) run a program within bash to do the communications.
    >
    > Others, I believe, have already explained how to do (a). To do
    > (b), the simplest thing would be to have a pair of named pipes
    > and then copy between those and the terminal. Your main program
    > could then read/write to the pipes instead of to a foreign terminal.
    > Another approach would be to use a TCP connection.


    I think the named-pipe solution would be nice. And, I remember there
    is a shell command used to create a named pipes, but I just forget
    it. Could you tell me and show a simple sample session letting me do
    a evaluation. Thanks a lot.

    -
    woody

    >
    > - Logan



  8. Re: How to read inputs from another terminal?

    >This is not pratical. The program under the question is actually an
    >TUI ( text user interface ) running on an embedded system. When in
    >case a system maintainer need to restart the TUI from a remote telnet
    >pseudo tty, it usually means, he or she can not touch to the running
    >system, so he can not execcute anything on it.
    >
    >>
    >> Personally, though, I think a cleaner design would be to either:
    >> (a) not have bash run at all, or

    >
    >I don't get the idea ... Would you explain?


    Use a terminal which has NO other uses whatever. Rip its name out
    of /etc/ttys and/or /etc/inittab so there is no login prompt on it
    when this program of yours isn't running.

    Another possibility is that you want to run whatever it is you
    ran with bash *IN THE FOREGROUND*, not in the background, so
    the shell is sitting there waiting for a telnet or whatever to finish.


  9. Re: How to read inputs from another terminal?

    On Apr 9, 1:18 pm, gordonb.y0...@burditt.org (Gordon Burditt) wrote:
    > >This is not pratical. The program under the question is actually an
    > >TUI ( text user interface ) running on an embedded system. When in
    > >case a system maintainer need to restart the TUI from a remote telnet
    > >pseudo tty, it usually means, he or she can not touch to the running
    > >system, so he can not execcute anything on it.

    >
    > >> Personally, though, I think a cleaner design would be to either:
    > >> (a) not have bash run at all, or

    >
    > >I don't get the idea ... Would you explain?

    >
    > Use a terminal which has NO other uses whatever. Rip its name out
    > of /etc/ttys and/or /etc/inittab so there is no login prompt on it
    > when this program of yours isn't running.
    >
    > Another possibility is that you want to run whatever it is you
    > ran with bash *IN THE FOREGROUND*, not in the background, so
    > the shell is sitting there waiting for a telnet or whatever to finish.


    Ok. I think I get it. Thanks.

  10. Re: How to read inputs from another terminal?

    Steven Woody wrote:
    > On Apr 9, 9:30 am, Logan Shaw wrote:


    >> In order to stop this, you have to tell the shell to stop trying to
    >> read from the terminal. One way is to type something like this at the
    >> bash prompt:
    >>
    >> exec < /dev/null ; sleep 60 ; exec < /dev/tty


    > This is not pratical. The program under the question is actually an
    > TUI ( text user interface ) running on an embedded system. When in
    > case a system maintainer need to restart the TUI from a remote telnet
    > pseudo tty, it usually means, he or she can not touch to the running
    > system, so he can not execcute anything on it.


    I don't understand why that's relevant. It seems like you already
    said that the program running the TUI is started and stopped from
    some other terminal. That's why you have to connect to a second
    "foreign" terminal in the first place, right? The "sleep 60" (or
    whatever infinitely-delaying program that it is a placeholder for)
    would be run on the "foreign" terminal just to stop the shell from
    reading from the terminal. So that program would not need to be
    restarted, since it is never doing anything but giving the shell
    something to wait on.

    By the way, I realized the above was overly complex. You don't need
    to redirect the shell's stdin while the foreground command is running.
    It is enough that a foreground command is running; because of that,
    the shell will not normally read from the terminal. So you could just
    do this:

    sleep 60

    Or to make it wait forever:

    while : ; do sleep 86400 ; done

    Of course you can use a larger number than 86400. I just think that's
    a nice "round" number (in terms of dates).

    - Logan

  11. Re: How to read inputs from another terminal?

    On Apr 10, 10:12 am, Logan Shaw wrote:
    > Steven Woody wrote:
    > > On Apr 9, 9:30 am, Logan Shaw wrote:
    > >> In order to stop this, you have to tell the shell to stop trying to
    > >> read from the terminal. One way is to type something like this at the
    > >> bash prompt:

    >
    > >> exec < /dev/null ; sleep 60 ; exec < /dev/tty

    > > This is not pratical. The program under the question is actually an
    > > TUI ( text user interface ) running on an embedded system. When in
    > > case a system maintainer need to restart the TUI from a remote telnet
    > > pseudo tty, it usually means, he or she can not touch to the running
    > > system, so he can not execcute anything on it.

    >
    > I don't understand why that's relevant. It seems like you already
    > said that the program running the TUI is started and stopped from
    > some other terminal. That's why you have to connect to a second
    > "foreign" terminal in the first place, right? The "sleep 60" (or
    > whatever infinitely-delaying program that it is a placeholder for)
    > would be run on the "foreign" terminal just to stop the shell from
    > reading from the terminal. So that program would not need to be
    > restarted, since it is never doing anything but giving the shell
    > something to wait on.



    'sleep' run on what terminal? say, TA is the terminal I expected the
    program outpus/inputs, and TB is the termial I operated. TA is
    untouchable. So you mean the 'sleep' run on TB, right? That hence
    locks the TB, so any sense does it make?

    >
    > By the way, I realized the above was overly complex. You don't need
    > to redirect the shell's stdin while the foreground command is running.
    > It is enough that a foreground command is running; because of that,
    > the shell will not normally read from the terminal. So you could just
    > do this:
    >
    > sleep 60
    >
    > Or to make it wait forever:
    >
    > while : ; do sleep 86400 ; done
    >
    > Of course you can use a larger number than 86400. I just think that's
    > a nice "round" number (in terms of dates).
    >
    > - Logan



  12. Re: How to read inputs from another terminal?

    On Apr 10, 11:29 am, Steven Woody wrote:
    > On Apr 10, 10:12 am, Logan Shaw wrote:
    >
    >
    >
    > > Steven Woody wrote:
    > > > On Apr 9, 9:30 am, Logan Shaw wrote:
    > > >> In order to stop this, you have to tell the shell to stop trying to
    > > >> read from the terminal. One way is to type something like this at the
    > > >> bash prompt:

    >
    > > >> exec < /dev/null ; sleep 60 ; exec < /dev/tty
    > > > This is not pratical. The program under the question is actually an
    > > > TUI ( text user interface ) running on an embedded system. When in
    > > > case a system maintainer need to restart the TUI from a remote telnet
    > > > pseudo tty, it usually means, he or she can not touch to the running
    > > > system, so he can not execcute anything on it.

    >
    > > I don't understand why that's relevant. It seems like you already
    > > said that the program running the TUI is started and stopped from
    > > some other terminal. That's why you have to connect to a second
    > > "foreign" terminal in the first place, right? The "sleep 60" (or
    > > whatever infinitely-delaying program that it is a placeholder for)
    > > would be run on the "foreign" terminal just to stop the shell from
    > > reading from the terminal. So that program would not need to be
    > > restarted, since it is never doing anything but giving the shell
    > > something to wait on.

    >
    > 'sleep' run on what terminal? say, TA is the terminal I expected the
    > program outpus/inputs, and TB is the termial I operated. TA is
    > untouchable. So you mean the 'sleep' run on TB, right? That hence
    > locks the TB, so any sense does it make?
    >
    >
    >
    > > By the way, I realized the above was overly complex. You don't need
    > > to redirect the shell's stdin while the foreground command is running.
    > > It is enough that a foreground command is running; because of that,
    > > the shell will not normally read from the terminal. So you could just
    > > do this:

    >
    > > sleep 60

    >
    > > Or to make it wait forever:

    >
    > > while : ; do sleep 86400 ; done

    >
    > > Of course you can use a larger number than 86400. I just think that's
    > > a nice "round" number (in terms of dates).

    >
    > > - Logan


    Sorry, I get understand your point. That's right and thank you.

+ Reply to Thread