Questions about zpty module.

Questions about zpty module.

[Andrej Borsenkow]

- does zsh reads pty output line by line? Or does it just reads what happens
to be in buffer? How is it related to blocking/non-blocking modes?

- manual says:

     The -r option can be used to read the output of the command NAME.
     Without a PARAM argument, the string read will be printed to
     standard output. With a PARAM argument, the string read will be
     put in the parameter named PARAM. If the PATTERN is also given,
     output will be read until the whole string read matches the
     PATTERN.

what is exactly mentioned "string" that is matched against PATTERN? Is it
the whole input? That is, in case

zpty -r command var '*\n'

will zsh wait until it reads the whole line? What happens in case of
non-blocking read then? In this case read can return with only part of
input.

- is it possible to know, if write was successful (or how many characters
were actually written)? In case of non-blocking fd and full pipe write() can
return with only partial buffer (or none at all) written

- what about read/write with timeout? It can avoid problems with
non-blocking mode while providing safe way to detect external program
failure.

/andrej

Re: Questions about zpty module.

[Bart Schaefer]

On Mar 3,  5:28pm, Andrej Borsenkow wrote:
} Subject: Questions about zpty module.
}
} - does zsh reads pty output line by line?

No.  It reads it one byte at a time, actually, and dynamically resizes
the buffer as necessary.

} Or does it just reads what happens to be in buffer?

Most of the time, yes, because the read-one-byte loop runs until the
non-blocking read fails.

} How is it related to blocking/non-blocking modes?

It's a bit strange.  Because of the tight read-one-byte loop, zsh will
consume data from the PTY slave side as fast as the slave produces it,
and will attempt to buffer it all up before it does anything else with
it.  This seems rather dangerous to me; the slave could simply spew an
endless stream and zsh would eat all available memory.

} - manual says:
} 
}      [...]  If the PATTERN is also given,
}      output will be read until the whole string read matches the
}      PATTERN.
} 
} what is exactly mentioned "string" that is matched against PATTERN? Is it
} the whole input?

The whole input.

} That is, in case
} 
} zpty -r command var '*\n'
} 
} will zsh wait until it reads the whole line?

Once again the answer is "most of the time."  If the slave spits out the
bytes faster than zsh can read them, it'll read straight past the first
newline before it ever gets around to testing the pattern.

} What happens in case of
} non-blocking read then? In this case read can return with only part of
} input.

Reading too little data from the PTY won't matter, because zsh loops
around again if the pattern doesn't match.  Reading TOO MUCH is what
I'm concerned about.

If you don't use the pattern-matching option, then yes, zsh might read
only part of the slave's output.

} - is it possible to know, if write was successful (or how many characters
} were actually written)? In case of non-blocking fd and full pipe write()
} can return with only partial buffer (or none at all) written

Yes, that looks like another potential bug to me: ptywrite() doesn't do
anything to make sure the write succeeded or wrote all of its data.  A
PTY isn't a "pipe" so the buffering is somewhat different, but still ...

} - what about read/write with timeout? It can avoid problems with
} non-blocking mode while providing safe way to detect external program
} failure.

That's not really necessary.  Ideally, the PTY slave jobs would use the
regular zsh job table so zsh could detect their exits.  I suppose this
was not done to isolate handling to the zpty module -- it'd require
special handling because those jobs should never be brought into the
foreground.

As it stands, there's a race condition in the handling of those jobs;
if the PTY slave is alive before zsh enters ptyread() but dies before
zsh reads something to match the pattern, ptyread() loops forever.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com