In article <
de6125db-f1e3-4ebf...@googlegroups.com>,
Andrew Schorr <
asc...@telemetry-investments.com> wrote:
>On Sunday, February 22, 2015 at 9:11:26 AM UTC-5, Kenny McCormack wrote:
>> Now, my understanding is that in the latest versions of GAWK, there is some
>> kind of mechanism for addressing this - some sort of method for "re-wiring"
>> GAWK's basic I/O mechanisms.
>
>Yes, such a mechanism exists. You can register an input parser that will replace
>the normal function used to read a record of input.
Curiously enough, I had just now gotten around to doing some research on
this problem, so I was probably reaching these same conclusions at the
exact same time as you were composing and posting your response.
>But I think it might be
>rather painful to do this, since I don't see a simple way to stack this
>functionality on top of the existing code to read a record. In other words, for
>the minor gain of printing a prompt, I think you will need to implement all the
>hairy logic of reading and parsing input.
Interesting. However, in looking through this, I found this line in io.c:
iop->public.read_func = ( ssize_t(*)() ) read;
And I suspect (although I have not gotten around to testing it yet) that if
I just point that at a wrapper function (e.g., 'my_read' instead of 'read'),
I will get what I want.
Note that since I have already made a lot of source code level tweaks to
the various renditions of GAWK on my systems, I am not averse to making
source code level changes and recompiling. To me, (i.e., for my own use)
there is no particular difference between tweaking the source code vs.
doing stuff in extension libs.
>The "readdir" and "readfile" extensions in the gawk distribution both register
>input parsers, so those can serve as examples.
Yes, I've looked at those. It's pretty complicated stuff; I haven't fully
digested them yet.
>This feature is documented in the manual under "Input Parsers". The basic
>challenge is to implement a get_record function. This is tricky for the general
>case where RS could be a regular expression, etc.
As noted above, I am hopeful that I will not have to go down this road.
>> I think it is the same sort of underlying
>> method that is used to implement the "in-place" editing feature.
>
>The in-place editing feature does not register an input parser or output wrapper.
>It just uses some API function calls to redirect stdout to a temporary file which
>it renames to the source file at the end.
Correct. I did finally get around to digesting how inplace works, and can
see now that it does not involve the Input Parser mechanism.
Thanks for your reply!
--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."
- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -