Re: fflush & close behavior not well-defined

[Andrew J. Schorr]

Thanks for responding, but please always group-reply to share your thoughts
with the list. I am cc'ing the list. This is not my decision to make.

Regards,
Andy

On Mon, Sep 14, 2020 at 03:22:36PM -0400, pjfarley3@earthlink.net wrote:
> FWIW, I care at least a little bit as well.  I like Wolfgang's solution,
> including his caveat.
> 
> "   close("| md5sum") # close pipe
>    close(">md5sum" ) # close file
> Unless, of course, this creates another ambiguity :-)"
> 
> Second choice would be Manuel's suggestion of wrapper functions for close
> along with your own suggestion of a close_coprocess() wrapper.
> 
> But I must admit Arnold may be correct in this case.  If such issues became
> truly serious for someone, it may be they are using the wrong language to
> solve their problem.
> 
> (g)awk isn't the universal solution after all, we just sometimes like to
> pretend that it is.  :)
> 
> Peter
> 
> > -----Original Message-----
> > From: bug-gawk <bug-gawk-bounces+pjfarley3=earthlink.net@gnu.org> On
> > Behalf Of Andrew J. Schorr
> > Sent: Monday, September 14, 2020 2:19 PM
> > To: Neil R. Ormos <ormos-gnulists17@ormos.org>
> > Cc: Bug Gawk List <bug-gawk@gnu.org>
> > Subject: Re: fflush & close behavior not well-defined
> > 
> > On Mon, Sep 14, 2020 at 01:09:09PM -0500, Neil R. Ormos wrote:
> > > That is what I was suggesting.  I imagined that once the file had been
> > > opened, all that would be needed to update the global variable, for
> > > each I/O, would be to copy a pointer, which operation I further
> > > imagined to be so cheap, compared to actually launching the I/O, as to
> > > be "in the noise".
> > >
> > > Since you know the internals and I don't, I defer.
> > 
> > I don't think we want a new reserved global variable name, so we'd have to
> stick
> > it somewhere in PROCINFO. It's probably pretty cheap to do so, as you
> suggest,
> > but it feels inelegant to me.
> > 
> > > >> Then, a user who needs a non-ambiguous call to
> > > >> close() or fflush() could pass the handle instead of, or in
> > > >> addition to, the current filename argument?
> > >
> > > > I don't see why this is better than enhancing the close & fflush
> > > > functions to give them the info they need to find the correct file,
> > > > but maybe if you flesh out your idea with an example, I'll
> > > > understand better.
> > >
> > > I'm not sure it's /better/.  It just seems /cleaner/ to let the user
> > > account for and supply a single unambiguous identifier, than to
> > > require the user to supply both the name and type of the something
> > > that is to be close()-d or fflush()-ed, and then for close() or
> > > fflush() to hunt around for a match.
> > 
> > Unfortunately, awk does not have a concept of file handles, most likely
> because
> > there's no formal open statement. So yeah, we could materialize this
> concept in
> > the background, but it would feel more elegant if there were a function
> for this,
> > e.g. filehandle_lookup(filename, filetype), rather than doing it behind
> the scenes
> > via PROCINFO.  In theory, we could probably implement such a function in
> an
> > extension, but it feels to me like a mess to introduce a concept of hidden
> file
> > handles.
> > 
> > > Again, I recognize that you know the internals and I don't.
> > >
> > > And that both you and Arnold see this as something nobody actually
> > > cares about.
> > 
> > I care a little bit. Arnold cares approximately zero, as far as I can
> tell. :-) I'm
> > putting it out there to check the collective wisdom and raise awareness of
> this
> > subtle flaw.
> > 
> > Regards,
> > Andy
> 
> 

-- 
Andrew Schorr                      e-mail: aschorr@telemetry-investments.com
Telemetry Investments, L.L.C.      phone:  917-305-1748
152 W 36th St, #402                fax:    212-425-5550
New York, NY 10018-8765