----- Original Message -----
From: "Fairlight"
At Tue, Dec 16, 2008 at 04:24:44PM -0500 or thereabouts, suspect Kenneth Brody was observed uttering:
Quoting Fairlight (Tue, 16 Dec 2008 15:59:41 -0500):
Is it possible to generate EOF on the outgoing stream to a program without closing the entire USER session? Likewise, how do you detect EOF on the incoming stream from USER if the external isn't purposely built for use with fP?
The only way to generate EOF on a pipe is to close the pipe.
Which...I of course knew. :) Guess I'm more tired than I thought, re-reading the question and how I phrased it. Not to mention being ill. Bleh.
I just figured maybe you had a mechanic hidden away in there that wasn't exactly advertised and didn't rely on the pipe. Could have been more to it than that.
Okay, so USER is pretty much useless in a scenario where you need to give something STDIN from fP's STDOUT, and get the STDOUT from the process back. There's no way to EOF it and read back all in one session. I can think of a few (ugly, ugly, UGLY) ways to work around this, but... Yeah, the suggestion of USER from earlier in the week is a non-starter.
user is very useful sometimes, but very delicate and very easy to lock up. I only dare use it when the target program is written specifically to be used with user so that I can know for certain at all times whether I need to be reading or writing so that I can reliably stay in sync, and even then I keep the interface dead simple. The thing I use it for most is just a forever looping read-one-line-write-one-line . And I don't try to be fancy with the filepro processing. All use of the user alias is in a gosub and the gosub includes the user command that opens the pipe, and never closes it, relying on the fact that filepro doesn't actually spawn further instances of the target program when re-executing the same user command. So subsequent calls to the gosub just end up using the already open pipe. That way I am in no risk of having code focus jump around and possibly miss a beat wrt to interacting with the user program. If you try to read form user when the app isn't writing, you hang until the app sends you an end of line. If you try to write to user when the app isn't reading, you hang until the app reads your line. Both of which usually never happen so you hang forever. Which means it's extremely easy to get hung unless all 3 of: - the app, or a wrapper around something else, was written specifically with this in mind so it has a consistent , reliable, predictable interface that always does the same thing, the same sequence of reads & writes, and loops forever (the looping is because user procs dont' close and go away cleanly, they make zombies until the clerk process goes away, so instead of closing & opening new instances, it's actually better to open one and leave it waiting for input even if you might never use it a 2nd time in that clerk session.) - the interface, the conversation I like to call it, with the app is kept as simple as possible. - the filepro code takes no chances at all and conducts the entire conversation in one unbroken gosub or call, no multiple exits or returns from that routine, and as little jumping around as possible within that routine. It's been a fine and reliable solution to the few problems I've applied it to, when treated that way, but no way would I use user for any arbitrary program without some kind of shell wrapper. It's theoretically possible to interact with any program if you know that programs entire range of actions perfectly, you could write filepro processing to interpret all possible output so that you always know what to expect next, based on what you last received or sent, but that would get pretty non-trivial pretty fast, and still wouldn't handle when the app simply failed. Stockler, Esac or JPR had some examples somewhere using bc as the target app. I have used it to get tcp functionality, by using netcat as the target app and having good full documentation of the tcp service I was contacting. Not Pretty. Other times I use a wrapper so that the filepro-user interface was simple and had a fixed pattern and did the adaptive stuff interacting with netcat and the remote service in shell or perl. filepro file i/o commands can read & write to named pipes so you might in some cases be able to do a little better than using system() and temp files and/or env variables. You could use system() to execute the app and use file i/o to read/write one or more fifos without blocking the way user does. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org