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

[Andrew J. Schorr]

Hi Janis,

[Adding back CC to bug-gawk]

On Wed, Jun 10, 2015 at 03:53:32PM +0200, Janis Papanagnou wrote:
> Are you proposing that I shall first file a bug report to the sed folks and
> wait for their fix (or rejection) before gawk considers it?  :-)

You'll have to file the bug with the perl maintainers as well:

bash-4.2$ echo hello > test
bash-4.2$ chmod -w test
bash-4.2$ ls -l test
-r--r--r-- 1 schorr ead 6 Jun 10 10:21 test
bash-4.2$ perl -i -ne 's/hello/goodbye/; print;' test && echo YES
YES
bash-4.2$ cat test
goodbye
bash-4.2$ ls -l test
-r--r--r-- 1 schorr ead 8 Jun 10 10:21 test

> I use sed only marginally and GNU awk a lot, so I don't much care about
> how sed behaves. I do care how awk behaves, though.
> 
> Don't you think that this is a buggy or undesired behaviour in GNU awk?

I don't think it's a bug.  The fact that every other tool handles this the
same way suggests to me that I'm not a lunatic.  We are not modifying the
file.  We are creating a new file and then replacing it.  As such, it is
the directory's permissions that matter, not the file's.  Furthermore,
you can provide INPLACE_SUFFIX to save a copy of the original file.

If you are concerned about this case, then I think you need to check it
yourself.  I think the inplace extension is working properly.

> I am aware and admit that the manual documents it:
>     "[...] configured to have the same owner
> and permissions as the original."
> but that does (IMO) not make it a sane behaviour to overwrite (and clear)
> any original write-only file, circumventing the deliberate file protection 
> set.
> 
> 
> However you will judge, fixing that or not.

I'm not the judge.  This is an open-source project, and I am not the
maintainer.  If you feel strongly enough that the behavior should be changed,
then I recommend that you submit a proposed patch for the developers to
discuss.  Or at the very least, you should specify what you would like to
happen in this case.  Should awk give a fatal error?  Should there be a way
to override this additional permission check?  It sounds like a can of
worms to me.

> The GNU awk manual should
> be more precise on the 'inplace' behaviour. I actually stumbled across
> that when I tried means to circumvent another 'inplace' behaviour - I
> posted about that in Usenet today, so I spare to repeat it here.
> The manual says:
>     "For each regular file that is processed, the extension redirects
> standard output to a temporary file [...]"
> Now for the case of a file that is only read there is no "standard output"
> written, and it's arguable whether the original file shall be emptied in
> that case, as the current implementation does. In other, similar cases
> awks do not behave that way; e.g. if you conditionally redirect to a file:
>     cond { print > "file" }
> the file will *not* be overwritten if the condition 'cond' does never match.
> I think a similar logic might be appropriate to not replace files by empty
> files if there's never anything written to stdout while the respective file
> is processed. - I'm sure you can find rationales for both behaviours
> (although in my book it's rather clear). But in any case it should be made
> clearer in the documentation, including caveats if it's kept as it currently
> is.

I'm not sure from this description that the documentation is defective.  I just
read it again, and it's quite explicit about how the inplace feature is
implemented.  If you think the documentation comes up short, then the best
approach is for you to propose specific changes to the wording.  A proposed
patch would be even better.  It's a lot of work to maintain and develop the
code and documentation, and we appreciate all the help we can get!

Regards,
Andy