Actually I believe that all reads from a null device immediately receive a terminating character (CR). All writes also complete successfully without problems. That's the purpose of the null device.
The thing that often causes looping code is a call to a fileman utility with bad data (i.e. doesn't match input transform) and the error message is displayed to and then read from the null device and gets a <CR>. You'll often see evidence of it in the fileman variables. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Woodhouse Sent: Monday, February 06, 2006 8:08 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] "Silent" Fileman calls not silent On Feb 6, 2006, at 6:45 PM, Gregory Woodhouse wrote: > On Feb 6, 2006, at 6:02 PM, Steven McPhelan wrote: > >> You never want to READ from the NULL device, especially with >> something like "Press return to continue" as the application may get >> stuck in a infinite READ loop especially if the READ answer is >> required. > > I see what you mean. Even with a * or # read (both forbidden by the > SAC), a read from NULL should fail immediately. Even so, a lot of > programmers interpret a null result to mean the user just pressed > enter. At any rate, having code that does anything of this sort in a > data dictionary is VERY strange (which isn't to say it's never > happened). > > Out of curiosity, I tested this in Cache (no Kernel involved) > > csession cache > > USER>O "/dev/null" > > USER>U "/dev/null" R X#1 > > USER>W $L(X) > 0 > > > It seems to me much more sensible to raise an error when EOF is > encountered than just return an empty string, but a lot of code seems > to assume that trying to read past EOF will just silently. > Just for fun, this is C ~:$ cat test.c #include <stdio.h> int main() { FILE *fp; int c; fp = fopen("/dev/null", "r"); if ((c = fgetc(fp)) == EOF) printf("end of file!\n"); } ~:$ cc test.c ~:$ a.out end of file! ~:$ === Gregory Woodhouse [EMAIL PROTECTED] "The most profound technologies are those that disappear." --Mark Weiser ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
