The "READ_TIMEOUT" functionality: Fatal error?

[Kenny McCormack]

My GAWK version is:

GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.1)

In BEGIN, I use:

PROCINFO["-","READ_TIMEOUT"] = 2000;

When timeout occurs, it causes a fatal error message to be displayed
and the script is aborted.

I seem to remember that in an earlier round of playing with the timeout
feature, it was possible to catch the error and to continue processing.

ISTR that your set something in PROCINFO, something like:

PROCINFO["-","error"] = non-fatal;

Something like that, but I can't find it in "man gawk" now.

What am I not remembering correctly?

--
Note that Oprah actually is all the things that The Donald only wishes he were.
For one thing, she actually *is* a billionaire. She's also actually self-made,
came from nothing, knows how to run businesses, never went bankrupt, is smart
and is mentally stable.

[Manuel Collado]

El 13/02/2018 a las 6:17, Kenny McCormack escribió:
> My GAWK version is:
>
> GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.1)
>
> In BEGIN, I use:
>
> PROCINFO["-","READ_TIMEOUT"] = 2000;
>
> When timeout occurs, it causes a fatal error message to be displayed
> and the script is aborted.
>
> I seem to remember that in an earlier round of playing with the timeout
> feature, it was possible to catch the error and to continue processing.
>
> ISTR that your set something in PROCINFO, something like:
>
> PROCINFO["-","error"] = non-fatal;
>
> Something like that, but I can't find it in "man gawk" now.
>
> What am I not remembering correctly?
>

The BEGINFILE/ENDFILE section of the manual says:

"Normally, when an error occurs when reading input in the normal
input-processing loop, the error is fatal. However, if an ENDFILE rule
is present, the error becomes non-fatal, and instead ERRNO is set.
This makes it possible to catch and process I/O errors at the level
of the awk program."

HTH.

--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

[Kenny McCormack]

In article <5A82B1F5...@users.sourceforge.net>,
Manuel Collado <m-co...@users.sourceforge.net> wrote:
...

>The BEGINFILE/ENDFILE section of the manual says:
>
>"Normally, when an error occurs when reading input in the normal
>input-processing loop, the error is fatal. However, if an ENDFILE rule
>is present, the error becomes non-fatal, and instead ERRNO is set.
>This makes it possible to catch and process I/O errors at the level
>of the awk program."

Yes, thanks. That does jog my memory. So, I wrote a little bash script,
whose output is shown below:

--- Cut Here ---
In BEGINFILE, FIELNAME = lsdfjlsd ERRNO = No such file or directory
In ENDFILE, FIELNAME = - ERRNO = Operation timed out
1 #!/bin/bash
2 gawk4 'BEGIN { PROCINFO["-","READ_TIMEOUT"] = 5000 }
3 BEGINFILE { if (ERRNO) { print "In BEGINFILE, FIELNAME =",FILENAME,"ERRNO =",ERRNO;nextfile }}
4 ENDFILE { if (ERRNO) { print "In ENDFILE, FIELNAME =",FILENAME,"ERRNO =",ERRNO }}
5 { print NR,$0 }' lsdfjlsd - $0
--- Cut Here ---

The interesting thing is that, in order to catch both kinds of errors, you
need both BEGINFILE and ENDFILE rules. And note that you need nextfile in
the BEGINFILE rule, but not in the ENDFILE - in fact, it is a fatal error
to have "nextfile" in an ENDFILE rule.

It is also interesting/odd (but not in a bad way), that it works like this.
It is like including the ENDFILE rule is like setting up a signal handler
in a C program. Without the signal handler, the signal is a fatal error,
but the inclusion of the signal handler makes it catchable.

P.S. It is also a bit odd that GAWK uses "ERRNO" for the textual error
string. Obviously, this is based on the underlying C "errno" variable -
but converted to text (presumably with strerror()), but, really, in GAWK
the variable should have been something like ERRTEXT.

--
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

[Kaz Kylheku]

On 2018-02-13, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> P.S. It is also a bit odd that GAWK uses "ERRNO" for the textual error
> string. Obviously, this is based on the underlying C "errno" variable -
> but converted to text (presumably with strerror()), but, really, in GAWK
> the variable should have been something like ERRTEXT.

That's especially too bad given that low-ish values of errno are
usefully portable across platforms.

That is to say, you can set up your own

einval = 22

and compare errno values to that; it will actually correspond to EINVAL
on many systems.

See table here: http://www.ioplex.com/~miallen/errcmp.html

[Andrew Schorr]

On Tuesday, February 13, 2018 at 12:17:02 AM UTC-5, Kenny McCormack wrote:
> ISTR that your set something in PROCINFO, something like:
>
> PROCINFO["-","error"] = non-fatal;
>
> Something like that, but I can't find it in "man gawk" now.
>
> What am I not remembering correctly?

I think you want PROCINFO[<output>, "NONFATAL"]. See docs here:

https://www.gnu.org/software/gawk/manual/html_node/Nonfatal.html

Regards,
Andy

[Andrew Schorr]

On Tuesday, February 13, 2018 at 10:57:35 AM UTC-5, Kenny McCormack wrote:
> P.S. It is also a bit odd that GAWK uses "ERRNO" for the textual error
> string. Obviously, this is based on the underlying C "errno" variable -
> but converted to text (presumably with strerror()), but, really, in GAWK
> the variable should have been something like ERRTEXT.

See:
https://www.gnu.org/software/gawk/manual/html_node/Auto_002dset.html

If the value of ERRNO corresponds to a system error in the C errno variable, then PROCINFO["errno"] will be set to the value of errno. For non-system errors, PROCINFO["errno"] will be zero.

Regards,
Andy

[Kenny McCormack]

In article <de8c1c77-66c1-4716...@googlegroups.com>,

Yes, thanks.

A couple of notes:

1) It seems both of these features (this one and the ERRNO one) are
recent arrivals. I'm still running 4.1.4 on my systems and the man page
for that version doesn't have either one of these. One of these days, I'll
get around to building 4.2.1.

2( Why is the above thing (the NONFATAL thing) only for output streams?
Why not also for input streams - especially since that's the actual topic
of this thread?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/ModernXtian

[Andrew Schorr]

On Wednesday, February 14, 2018 at 1:42:14 AM UTC-5, Kenny McCormack wrote:
> 1) It seems both of these features (this one and the ERRNO one) are
> recent arrivals. I'm still running 4.1.4 on my systems and the man page
> for that version doesn't have either one of these. One of these days, I'll
> get around to building 4.2.1.

Correct. These are new features in 4.2.x. I hope 4.2.1 will be out soon,
since 4.2.0 has a few bugs.

> 2( Why is the above thing (the NONFATAL thing) only for output streams?
> Why not also for input streams - especially since that's the actual topic
> of this thread?

Strangely enough, your topic titles do not drive development that was done
months, if not years, ago. :-) For the most part, "NONFATAL" applies to
output streams, although there is one exception, as per

https://www.gnu.org/software/gawk/manual/html_node/Two_002dway-I_002fO.html

'CAUTION: Normally, it is a fatal error to write to the "to" end of a two-way pipe which has been closed, and it is also a fatal error to read from the "from" end of a two-way pipe that has been closed.

You may set PROCINFO["command", "NONFATAL"] to make such operations become nonfatal. If you do so, you then need to check ERRNO after each print, printf, or getline. See Nonfatal, for more information.'

When it comes to input, the situation is a bit different. If getline returns
an error, it's not fatal. So the new "NONFATAL" facility doesn't really apply.
Instead, we have PROCINFO["command", "RETRY"], which you can read about here:

https://www.gnu.org/software/gawk/manual/html_node/Retrying-Input.html

I think that does what you want.

Regards,
Andy