Pseudo tty - how to find if slave program is requesting terminal input? - Unix

This is a discussion on Pseudo tty - how to find if slave program is requesting terminal input? - Unix ; I am creating a pseudo-tty on Solaris to "drive" a shell program on the
slave side. The tty is set to canonical, meaning input is sent a line
at a time. From my main program, I want to know if ...

Pseudo tty - how to find if slave program is requesting terminal input?

I am creating a pseudo-tty on Solaris to "drive" a shell program on the
slave side. The tty is set to canonical, meaning input is sent a line
at a time. From my main program, I want to know if the shell (the slave
program) has requested a read. How can I find that out in the main
program? Some ioctl flag, maybe?

The main program is reading shell commands from a file and sending to
the slave for execution. The main program can cause buffer overflow if
it sends all the input in one stream of writes, hence I want to check
if the slave is requesting input and only then send a line for
processing.

Re: Pseudo tty - how to find if slave program is requesting terminal input?

In article <1121616190.868166.103370@g14g2000cwa.googlegroups. com>,
"stilllearning" wrote:
> I am creating a pseudo-tty on Solaris to "drive" a shell program on the
> slave side. The tty is set to canonical, meaning input is sent a line
> at a time. From my main program, I want to know if the shell (the slave
> program) has requested a read. How can I find that out in the main
> program? Some ioctl flag, maybe?

I don't think there's any built-in way to tell.
> The main program is reading shell commands from a file and sending to
> the slave for execution. The main program can cause buffer overflow if
> it sends all the input in one stream of writes, hence I want to check
> if the slave is requesting input and only then send a line for
> processing.

The writes to the master side will blockif the buffer gets full (or
report EWOULDBLOCK if you've got it in non-blocking mode), so you should
never overflow.

Re: Pseudo tty - how to find if slave program is requesting terminal input?

On Sun, 17 Jul 2005 09:03:10 -0700, stilllearning wrote:
> The main program is reading shell commands from a file and sending to
> the slave for execution. The main program can cause buffer overflow if
> it sends all the input in one stream of writes, hence I want to check
> if the slave is requesting input and only then send a line for
> processing.

It would be a little better if you read from the pty slave and try to
interpret the output as successful or not. Otherwise you could get errors
and would just keep feeding it commands that would do who knows what.

I have some code that simplifies running a program in a pty a little. It's
MIT licensed so you can use bits of it (e.g. the part that reads from the
slave and tries to match it to one of a set of user supplied patterns)
or the whole thing if you have forkpty(3).

Re: Pseudo tty - how to find if slave program is requesting terminal input?

Michael B Allen,

Please verify and resend the URL; there is a space in the URL you have
mentioned:http://www.io plex.com/~miallen/libmba/dl/do*cs/ref/sho.html

Re: Pseudo tty - how to find if slave program is requesting terminal input?

There are issues with "expect". I cannot write a generic shell "driver"
because:

(1) The prompt string has to be known in advance. I do not want to
hand-craft "expect" programs. Also, different prompts may be issued at
different stages.

(2) Some programs may read input without prompting.

(3) Prompts have to be unique enough not to occur in output strings.

Since the slave program is forked from the main program, I may have
access to the slave side of the pseudo-tty. Is there a flag or
parameter there to determine if a read has been issued by the slave
program?

Re: Pseudo tty - how to find if slave program is requesting terminal input?

On Sun, 17 Jul 2005 10:36:27 -0700, stilllearning wrote:
> There are issues with "expect". I cannot write a generic shell "driver"
> because:
>
> (1) The prompt string has to be known in advance. I do not want to
> hand-craft "expect" programs. Also, different prompts may be issued at
> different stages.

So set it with putenv("PS1=SomEThIngtOTaLlyUniqUE$").
> (2) Some programs may read input without prompting.

Well regardless of what you do you have to know in advance what the
program expects and what it can return. Assuming that it cannot return an
error or return some unexpected output is not very robust. You really
should emulate what someone would do typing in a tty w/ complete with
Ctrl-C's to interrupt a hung program, extra linefeeds, etc.

Mike

Re: Pseudo tty - how to find if slave program is requesting terminal input?

In article ,
Michael B Allen wrote:
> On Sun, 17 Jul 2005 10:36:27 -0700, stilllearning wrote:
>
> > There are issues with "expect". I cannot write a generic shell "driver"
> > because:
> >
> > (1) The prompt string has to be known in advance. I do not want to
> > hand-craft "expect" programs. Also, different prompts may be issued at
> > different stages.
>
> So set it with putenv("PS1=SomEThIngtOTaLlyUniqUE$").

Only the shell uses PS1. If he runs another program from the shell and
it prompts for input, it won't use that prompt.

Re: Pseudo tty - how to find if slave program is requesting terminal input?

In theory, your comments make sense. However, there are trade-offs. The
more robust you want to make a program, the more time you need to
invest. I have spend a lot of time writing expect (from Perl) scripts
to automate tasks. The effort is tremendous. It is difficult to
consider, and tedious, to account for all possible program outputs. And
when there are program changes, the scripts have to be modified. The
shell driver I want to write is not robust, but a quick solution for
many simple, yet repetitive tasks.

BTW, you do not always know in advance what the program returns; you
want to send a line when the program requests one.

A side note about a general purpose Unix login automation. It is very
difficult to write such a program. You have to consider MOTD, various
prompts that can also be present in the MOTD and other verbiage,
possible invalid passwords and such.