From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14601 invoked from network); 4 Mar 2000 06:19:56 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Mar 2000 06:19:56 -0000 Received: (qmail 2266 invoked by alias); 4 Mar 2000 06:19:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9991 Received: (qmail 2246 invoked from network); 4 Mar 2000 06:19:48 -0000 From: "Bart Schaefer" Message-Id: <1000304061943.ZM23985@candle.brasslantern.com> Date: Sat, 4 Mar 2000 06:19:43 +0000 In-Reply-To: <000601bf851c$cff2af30$21c9ca95@mow.siemens.ru> Comments: In reply to "Andrej Borsenkow" "Questions about zpty module." (Mar 3, 5:28pm) References: <000601bf851c$cff2af30$21c9ca95@mow.siemens.ru> X-Mailer: Z-Mail (5.0.0 30July97) To: "ZSH workers mailing list" Subject: Re: Questions about zpty module. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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