Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Question about GNU awk's 'inplace' feature

50 views
Skip to first unread message

Janis Papanagnou

unread,
May 11, 2015, 2:12:57 PM5/11/15
to
I'm not using the inplace feature but I saw an interesting question about
it on StackExchange, and I wondered whether that is intentional or a bug:

In a program like:

awk -i inplace '
BEGIN {print "begin"}
$1=="11" {print "111" $2; next}
{print $0}
END {print "end"}
' in_out_file

The print arguments in the BEGIN and END section will not be part of the
in_out_file but printed on stdout, while the other two print will replace
the contents of that file.

Janis

Kenny McCormack

unread,
May 11, 2015, 4:01:55 PM5/11/15
to
In article <miqrf7$hm5$1...@news.m-online.net>,
I am an occasional user of "inplace". I think it is quite natty, in fact.

The behavior descibed above is not only "working as designed", but is a
feature. Think of it this way: Logically, the filename arguments in an AWK
program are out of scope in both BEGIN and END. They are only logically
accessible in the "main body" of the AWK program. Note: I say "logically"
because the exact implementation details are often a little bit messy, but
logically/conceptually, what I've stated is true. Now, since the "inplace"
feature is a function of the filename arugments (each is used, in turn, to
determine where the output goes), it therefore follows that the "inplace"
functionality is only active during the "main body" part of the AWK program.

P.S. Note also that you can sorta mess this up by doing a "naked" getline
in the BEGIN clause. This has the effect of starting up the "main input
loop" prematurely. I suspect (but have not tested) that doing so would
cause the "inplace" functionality to start working.

--
When people wish to comment on something on which they have personal
knowledge, but do not wish to convey the fact that it is personal
knowledge, they often qualify their statement with "it's my
understanding". For instance, it's my understanding that when some
women are depressed they sit on the futon in a Snuggie, watch Lifetime,
and eat a whole tub of Rocky Road ice cream.

Janis Papanagnou

unread,
May 11, 2015, 4:09:53 PM5/11/15
to
Right. I should have probably mentioned that changing BEGIN/END by BEGINFILE/
ENDFILE will not change the situation.

Janis

Kaz Kylheku

unread,
May 11, 2015, 5:01:38 PM5/11/15
to
On 2015-05-11, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> logically/conceptually, what I've stated is true. Now, since the "inplace"
> feature is a function of the filename arugments (each is used, in turn, to
> determine where the output goes), it therefore follows that the "inplace"
> functionality is only active during the "main body" part of the AWK program.

And indeed, if it weren't the case, what if multiple files are named?

Should the BEGIN and END actions be repeated in each file?

That would destroy their meaning.

Or should the first file get the BEGIN prints, and the last file get the END
prints?

That seems arbitrarily nonsensical.

Kenny McCormack

unread,
May 11, 2015, 5:11:10 PM5/11/15
to
In article <20150511...@kylheku.com>,
Kaz Kylheku <k...@kylheku.com> wrote:
>On 2015-05-11, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> logically/conceptually, what I've stated is true. Now, since the "inplace"
>> feature is a function of the filename arugments (each is used, in turn, to
>> determine where the output goes), it therefore follows that the "inplace"
>> functionality is only active during the "main body" part of the AWK program.
>
>And indeed, if it weren't the case, what if multiple files are named?

Quite so.

(That's what I was getting at when I said "each file is used, in turn")

--
"I have a simple philosophy. Fill what's empty. Empty what's full. And
scratch where it itches."

Alice Roosevelt Longworth

Janis Papanagnou

unread,
May 11, 2015, 5:16:47 PM5/11/15
to
On 05/11/15 23:01, Kaz Kylheku wrote:
> On 2015-05-11, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> logically/conceptually, what I've stated is true. Now, since the "inplace"
>> feature is a function of the filename arugments (each is used, in turn, to
>> determine where the output goes), it therefore follows that the "inplace"
>> functionality is only active during the "main body" part of the AWK program.
>
> And indeed, if it weren't the case, what if multiple files are named?
>
> Should the BEGIN and END actions be repeated in each file?
>
> That would destroy their meaning.

Indeed. But what about BEGINFILE/ENDFILE ?

Janis

> [...]


Andrew Schorr

unread,
May 11, 2015, 8:17:20 PM5/11/15
to
Hi Janis,

On Monday, May 11, 2015 at 5:16:47 PM UTC-4, Janis Papanagnou wrote:
> Indeed. But what about BEGINFILE/ENDFILE ?

I thought we fixed this issue in gwak-4.1.2:

bash-4.2$ git diff cffd09247c1681fbf3d5cad5253b3199704f83e7..e0c1194c4348e7adf99802461d45e3dd1bd192ff awklib/eg/lib/inplace.awk | cat -
diff --git a/awklib/eg/lib/inplace.awk b/awklib/eg/lib/inplace.awk
index 6403a22..d157465 100644
--- a/awklib/eg/lib/inplace.awk
+++ b/awklib/eg/lib/inplace.awk
@@ -5,10 +5,15 @@
# Please set INPLACE_SUFFIX to make a backup copy. For example, you may
# want to set INPLACE_SUFFIX to .bak on the command line or in a BEGIN rule.

+# N.B. We call inplace_end() in the BEGINFILE and END rules so that any
+# actions in an ENDFILE rule will be redirected as expected.
+
BEGINFILE {
- inplace_begin(FILENAME, INPLACE_SUFFIX)
+ if (_inplace_filename != "")
+ inplace_end(_inplace_filename, INPLACE_SUFFIX)
+ inplace_begin(_inplace_filename = FILENAME, INPLACE_SUFFIX)
}

-ENDFILE {
+END {
inplace_end(FILENAME, INPLACE_SUFFIX)
}

Are you sure this isn't working properly in 4.1.2? Somebody raised this issue previously (Kenny?), and the fix should be in there...

Regards,
Andy

Janis Papanagnou

unread,
May 11, 2015, 8:23:27 PM5/11/15
to
On 05/12/15 02:17, Andrew Schorr wrote:
> Hi Janis,
>
> On Monday, May 11, 2015 at 5:16:47 PM UTC-4, Janis Papanagnou wrote:
>> Indeed. But what about BEGINFILE/ENDFILE ?
>
> I thought we fixed this issue in gwak-4.1.2:

Thanks!
So the effect of the fix is that it will work for BEGINFILE/ENDFILE ?
(And wouldn't work for BEGIN/END because of the reasons mentioned in
this thread?)

>
> [...]
>
> Are you sure this isn't working properly in 4.1.2?

I was trying it with my 4.1.1 (the same version that the StackExchange user
seems to have used).

> Somebody raised this issue previously (Kenny?), and the fix should be in there...

I may have missed (or forgot) the discussion.

Janis

>
> Regards,
> Andy
>

Ed Morton

unread,
May 12, 2015, 8:26:50 AM5/12/15
to
It was me who raised the issue and I reported it by direct email to bug-gawk,
not in the NG.

Ed.

>
> Janis
>
>>
>> Regards,
>> Andy
>>
>

Andrew Schorr

unread,
May 12, 2015, 10:18:59 PM5/12/15
to
On Monday, May 11, 2015 at 8:23:27 PM UTC-4, Janis Papanagnou wrote:
> So the effect of the fix is that it will work for BEGINFILE/ENDFILE ?

I think it should. Please give it a try.

> (And wouldn't work for BEGIN/END because of the reasons mentioned in
> this thread?)

Correct. There's no file in scope during BEGIN/END, so no redirection occurs.
You should use BEGINFILE/ENDFILE to achieve what you want.

> I may have missed (or forgot) the discussion.

I seem also to have forgotten where the discussion occurred. Thanks to Ed Morton for raising this issue as a bug.

Regards,
Andy


Janis Papanagnou

unread,
May 12, 2015, 11:02:30 PM5/12/15
to
On 05/13/15 04:18, Andrew Schorr wrote:
> On Monday, May 11, 2015 at 8:23:27 PM UTC-4, Janis Papanagnou wrote:
>> So the effect of the fix is that it will work for BEGINFILE/ENDFILE ?
>
> I think it should. Please give it a try.

Yes, it works with gawk 4.1.2.

Janis

>[...]

0 new messages