bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] -i infile unexpected behavior


From: Ed Morton
Subject: Re: [bug-gawk] -i infile unexpected behavior
Date: Sun, 15 Mar 2015 22:16:31 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


On 3/15/2015 9:56 PM, Andrew J. Schorr wrote:
On Sun, Mar 15, 2015 at 09:13:09PM -0500, Ed Morton wrote:
Andy - the script below behaved as desired in my testing. I'd never really
write or advocate anyone else writing the script below or

      gawk -e '1; ENDFILE {print "bar"}' -i inplace file

though as the whole point of having

    awk -i inplace '...' file

is to provide a briefer, simpler solution to write than

    awk '...' file > tmp && mv tmp file

(analogous to "sed -i '...' file") and both of those are lengthier and more
complicated (even for multiple files) so then what would be the point?
Well, the revision I provided does help a bit:

bash-4.2$ echo foo > file
bash-4.2$ cat /tmp/Inplace.awk
# inplace --- load and invoke the inplace extension.

@load "inplace"

BEGINFILE {
   if (INPLACE_FILENAME)
       inplace_end(INPLACE_FILENAME, INPLACE_SUFFIX)
   inplace_begin(FILENAME, INPLACE_SUFFIX)
   INPLACE_FILENAME = FILENAME
}

END {
   inplace_end(FILENAME, INPLACE_SUFFIX)
}

bash-4.2$ awk -i /tmp/Inplace '1; ENDFILE {print "bar"}' file
bash-4.2$ cat file
foo
bar
bash-4.2$ awk -i /tmp/Inplace '1; END {print "bar"}' file
bar
bash-4.2$ cat file
foo
bar
bash-4.2$

It solves the "ENDFILE" problem, but does not fix the "END" case.  The
disadvantage is that we have to introduce a new global variable to
store the filename.

Is it worth making this change?

Regards,
Andy
IMHO it's definitely worthwhile doing as its much more intuitive than the current implementation. The fact that it doesn't solve the END problem is a minor inconvenience which can be waved away with a "use ENDFILE" statement and I assume that `BEGIN{print "foo"}` will not write to the first file so `END{print "foo"}` not writing to the last one is at least symmetrical. In this context there is no sed equivalent to END, just to ENDFILE, so this change would make `awk -i inplace` behave consistently with `sed -i`.

wrt the new global variable - In C by convention you should never start variables with double underscore (__) since that is reserved for compiler use, maybe the same or similar convention could be useful for awk variables that you don't want clashing with names the user might create/use?

    Ed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]