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.

[ Post a follow-up to this message ]

In article <1121616190.868166.103370@g14g2000cwa.googlegroups.com>,
"stilllearning" <shahswim@yahoo.com> 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.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[ Post a follow-up to this message ]

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).

http://www.io plex.com/~miallen/libmba/dl/docs/ref/sho.html

Mike

[ Post a follow-up to this message ]

In article <barmar-41F054.12134717072005@comcast.dca.giganews.com>,
Barry Margolin <barmar@alum.mit.edu> writes:
>In article <1121616190.868166.103370@g14g2000cwa.googlegroups.com>,
> "stilllearning" <shahswim@yahoo.com> wrote:
> 
>
>I don't think there's any built-in way to tell.

There isn't.

Shells can be told to produce a prompt sequence which is really
intended for human users to know when they are expecting input,
but you could look for this in your program.
 
>
>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.

Some implementations might do this, but I think you'll find others
don't, or you could find that having filled the buffer, you can't get an
interrupt character through and you could be deadlocked if no further
input is read for some reason. This is pretty much the same as when
typing ahead too far on a terminal.

Might be worth the OP looking at the 'expect' program.

--
Andrew Gabriel

[ Post a follow-up to this message ]

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=ADcs/ref/sho.html

[ Post a follow-up to this message ]

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?

[ Post a follow-up to this message ]

In article <1121621787.223529.42240@g47g2000cwa.googlegroups.com>,
"stilllearning" <shahswim@yahoo.com> writes:
>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?

No, but there is a way to see if unread data is buffered (at
least on STREAMS-based pty implementations -- not sure how
widespread it is in other implementations). You could check
this and not send any more data until there is no unread data
buffered.

Note that I haven't tried this -- that's for you to do.
I can think of all sorts of potential problems (like the ioctl
might block if there's a read blocked in the stream-head, and
the extra open fd might prevent the last close being indicated
back to the other side).

int length, i;
.
.
.
/* check STREAM-head to see if there's still any unread data */
length = 0;
i = ioctl(fd, I_NREAD, &length, sizeof(length));
if (i == 0 && length == 0) {
/* no data buffered in STREAM-head -- send more data now */
}

--
Andrew Gabriel

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

In article <pan.2005.07.17.20.58.57.694810@ioplex.com>,
Michael B Allen <mba2000@ioplex.com> wrote:

> On Sun, 17 Jul 2005 10:36:27 -0700, stilllearning wrote:
> 
>
> 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.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[ Post a follow-up to this message ]

In article <42da9d2b$0$38038$5a6aecb4@news.aaisp.net.uk>,
andrew@cucumber.demon.co.uk (Andrew Gabriel) writes:
>I can think of all sorts of potential problems (like the ioctl
>might block if there's a read blocked in the stream-head, and

Just had another thought...
Use poll(2) to check for input might be another (better) way
to do this.

--
Andrew Gabriel

[ Post a follow-up to this message ]