Re: [bug-gawk] gawk - 'inplace' feature ignores file's access flags (read-only)

[Andrew J. Schorr]

Hi Janis,

In the future, can you please group-reply to CC the mailing list?

On Wed, Jun 10, 2015 at 06:42:17PM +0200, Janis Papanagnou wrote:
> > > 
> > > The application case I mentioned is different, not at all about backups.
> > 
> > Sorry.  I see from comp.lang.awk that what you really want is to disable
> > the inplace feature for a single file.
> 
> Not quite. - I wanted to _work around_ the fact that input files that are
> read-only (i.e. never written) will - per 'inplace' design - be replaced by
> an empty file; i.e. the data erased.[*]
>
> [*] An unwritten file should IMO not be replaced; compare to the semantics
> of  cond{print >"file"}  to understand what I mean; "file" remains untouched
> if that action will not be triggered.

I hear you, but I disagree.  The whole concept of "inplace" editing is
that the program is acting as a filter.  This is how it works in sed and
perl and other utilities.  To have the behavior conditioned on whether
stdout is empty just doesn't make sense to me.  If the filter produces
no output, that's the same as producing a zero-length file.
It seems to me that you have a particular requirement that is not compatible
with the general concept of inplace editing.

The behavior of 'cond{print >"file"}' is totally unrelated to the concept
of inplace editing.  The analogy doesn't hold for me.

> >  Using "chmod -w" is not a great solution to that problem, I think.
> 
> No, it would have just been a workaround to maybe achieve what I needed
> without changing the awk program.[**]
> 
> [**] It was my misconception (and how I'd understand the design of such a
> feature) that the 'inplace' feature would not affect the internal structure of
> the awk program, but only how it works externally with I/O on files.
>
> Now, according to the implemented
> 'inplace' logic, I have to add an explicit `print` statement just to re-write 
> the
> file with the same contents it had before... - also not a great solution.  :-/

I agree that this is an inelegant solution.  If I were you, I'd load the
map file using getline in a BEGIN rule.

> The issue I opened here was just a spin-off that I thought would be worth
> reporting. - My thought was that the access issue was  - compared to the
> 'inplace' design - an obvious flaw.

Ah well, it's not obvious to me.  And sometimes things that seem blindingly
obvious to me are really not obvious at all to others.

Regards,
Andy