filePro with no stdin (was Re: Hosting filePro applications)

[Kenneth Brody]

Quoting Fairlight (Mon, 23 Jan 2006 19:25:24 -0500):
[...]
> rclerk 0>/dev/null 1>/dev/null 2>/dev/null
>
> Watch your CPU time on the process fly.  Note that it -only- races when
> STDIN is closed.  If you -only- close STDIN, it appears to race a
> little, but, not as hard--as opposed to the racing you'll see in
> realtime if all three main fd's are closed.

Is stdin really closed?  Given the syntax of the above, it looks as if
stdin is set to an output stream, rather than input.

In either case, the above would cause read()s on stdin to return right
away.  (Though it would indicate an error, rather than returning any
input.  And, a quick look at the source shows that this error would
probably act as if '\0' were read.)

[...]
> It's bad enough when this will happen if someone generates a
> keystroke-requiring error (say, a double-declared GLOBAL, Press Enter)

But that shouldn't cause any hangups, unless isatty() returns TRUE
for stdin in the above situation.  When the "*** A filePro/System
error has occurred ***" error message is displayed, if isatty() for
stdin returns FALSE, filePro will not wait for a keypress, but will
instead pause 10 seconds and continue.

You can confirm this by setting up a situation (such as a syntax error
in processing) and comparing:

    dclerk filename etc etc etc
to
    echo "" | dclerk filename etc etc etc

[...]
> If it happens in 5.0.14, I have no real reason to believe it was fixed
> in the upcoming 5.6 unless told otherwise.  Someone in the beta program
> would have to test that.

Well, now that the condition has been identified, it can be fixed.

Of course, the question becomes "what should filePro do if it needs
input and stdin is closed or at EOF?"

[...]
> Since I finally traced the specific trigger for the bug, I'm CC'ing
> support to put it through official channels to be fixed (hopefully).

Noted.

> Hope this helps.

It's a lot better than "filePro's input is a polling loop".  :-)

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com