gawk inplace - coding pattern

[Janis Papanagnou]

Using inplace with gawk I just stumbled over something, a bit surprised as
well as a bit annoyed. I wanted to use the "map" code pattern in the first
file to define substitutions to take place in subsequent data files. Here
is a small test case:

echo $'A aa\nB bb' >map
echo $'A\nB\nC' >file1
echo $'A\nB\nC' >file2

awk -i inplace '
NR==FNR { map[$1] = $2 ; next }
{ print map[$1] }
' map file1 file2

My initial surprise stems from the fact that after that processing the map
file was empty! Then I realized that despite the file 'map' is only *read*
it will be emptied due to the 'inplace' function. This means that I have
to work around that behaviour by changing the standard mapping code pattern
from
NR==FNR { map[$1] = $2 ; next }
to
NR==FNR { map[$1] = $2 ; print ; next }

(i.e. only in case I activate option 'inplace').

My expectation would have been that the 'inplace' would not make it necessary
to change the logic "inside" the awk code; I considered it just a convenience
feature to avoid explicit temporary files and explicit shell 'mv' commands.

From my perspective it seems more appropriate to only (inplace-)change a file
if it's actually written by the awk program using some of the print commands.

Now I wonder what you think is the "right way" to see that (or handle that).

Janis

[Kenny McCormack]

In article <ml8jjj$e0u$1...@news.m-online.net>,

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>Using inplace with gawk I just stumbled over something, a bit surprised as
>well as a bit annoyed. I wanted to use the "map" code pattern in the first
>file to define substitutions to take place in subsequent data files. Here
>is a small test case:
>
> echo $'A aa\nB bb' >map
> echo $'A\nB\nC' >file1
> echo $'A\nB\nC' >file2
>
> awk -i inplace '
> NR==FNR { map[$1] = $2 ; next }
> { print map[$1] }
> ' map file1 file2
>
>My initial surprise stems from the fact that after that processing the map
>file was empty! Then I realized that despite the file 'map' is only *read*
>it will be emptied due to the 'inplace' function.

This is all working-as-designed. The point is that 'inplace' is some
powerful magic, and it fundamentally changes the way AWK works.

Another way to work-around it is to load up your 'map' file inside BEGIN
using getline - since getline loops aren't affected by the 'inplace' magic.

In a way, it would be nice to be able to turn the 'inplace' magic on and
off on a per-file basis. That is, to be able to say "Do the 'inplace'
magic only for my 'main' file." Maybe some global flag, say, in
PROCINFO[].

--
A liberal, a moderate, and a conservative walk into a bar...

Bartender says, "Hi, Mitt!"

[Kenny McCormack]

In article <ml8jjj$e0u$1...@news.m-online.net>,
Janis Papanagnou <janis_pa...@hotmail.com> wrote:

...

>My expectation would have been that the 'inplace' would not make it necessary
>to change the logic "inside" the awk code; I considered it just a convenience
>feature to avoid explicit temporary files and explicit shell 'mv' commands.
>
>From my perspective it seems more appropriate to only (inplace-)change a file
>if it's actually written by the awk program using some of the print commands.
>
>Now I wonder what you think is the "right way" to see that (or handle that).

Here's another work-around. I took your script and edited it a bit to get:

$ cat InplaceFix.awk
@load "inplace"
BEGINFILE {
do_inplace = ARGIND > 1
if (do_inplace)
inplace_begin(FILENAME, INPLACE_SUFFIX)
}

ENDFILE {
if (do_inplace)
inplace_end(FILENAME, INPLACE_SUFFIX)
}

!do_inplace { map[$1] = $2;next }
{ print map[$1] }
$

Basically, what I did was to take inplace.awk and add it to my own code,
adding a flag variable that tells whether or not to do the 'inplace' magic
on the current file.

--
"Although written many years ago, Lady Chatterley's Lover has just
been reissued by the Grove Press, and this fictional account of the
day-to-day life of an English gamekeeper is still of considerable
interest to outdoor minded readers, as it contains many passages on
pheasant raising, the apprehending of poachers, ways to control vermin,
and other chores and duties of the professional gamekeeper.

"Unfortunately, one is obliged to wade through many pages of extraneous
material in order to discover and savor these sidelights on the
management of a Midlands shooting estate, and in this reviewer's opinion
this book cannot take the place of J.R. Miller's Practical Gamekeeping"
(Ed Zern, Field and Stream, November 1959, p. 142).

[Janis Papanagnou]

This is a quite extreme, code-wise large, workaround. Since it also requires
application code to change I fail to see what advantage it has compared to
adding the 'print' statement as in my original posting. A similar doubt I'd
have with the elsethread posted while-getline loop suggestion in the BEGIN
clause.

Obviously I was too naively looking at the 'inplace' feature, assuming that
it would just operate close to the (shell-) boundaries of the awk program.

Meanwhile I also continued with ideas, one was to invoke a 'chmod -w map',
i.e. making the map file read-only on file system level. Surprisingly gawk
doesn't respect that flag and overwrites (or rather replaces) it as well.
Doh! - This is hard. - No abort, not even a warning, and the file is gone.

Janis

[Janis Papanagnou]

On 10.06.2015 08:59, Kenny McCormack wrote:
> In article <ml8jjj$e0u$1...@news.m-online.net>,
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:

[...]

>>
>> My initial surprise stems from the fact that after that processing the map
>> file was empty! Then I realized that despite the file 'map' is only *read*
>> it will be emptied due to the 'inplace' function.
>

[...]

>
> In a way, it would be nice to be able to turn the 'inplace' magic on and
> off on a per-file basis. That is, to be able to say "Do the 'inplace'
> magic only for my 'main' file." Maybe some global flag, say, in
> PROCINFO[].

Maybe yet easier if gawk would just respect the read-only flags of the
filesystem and not change such files. (Currently gawk silently ignores
the read-only flag and overwrites the file.)

Janis

[Kenny McCormack]

In article <ml95bv$idq$1...@news.m-online.net>,

You gotta admit that both of the "solutions" you've proposed are klunky and
weird. Maybe effective, but, really, you want to "fix" this by changing
file permissions to read-only? I mean, if you're gonna do that, you might
as well just revert to the old way of using the shell to implement the
"inplace" functionality.

(Or by adding a silly extra 'print' statement into your AWK code so that
the "mapping" file gets overwritten every single time you run your script?)

My solution, of basically fixing the 'inplace.awk' include file, is on the
right track. It only looked verbose the way I presented it because, for
demonstration purposes, I included the code inline rather than that which
is the right, long-term, solution - fixing the include file itself, so that
the problem is fixed forevermore. See my next post/response for more
detail on this, but note for now that the idea was to implement was I
suggested in the paragraph above (the one that starts with "In a way...").

--
Here's a simple test for Fox viewers:

1) Sit back, close your eyes, and think (Yes, I know that's hard for you).
2) Think about and imagine all of your ridiculous fantasies about Barack Obama.
3) Now, imagine that he is white. Cogitate on how absurd your fantasies
seem now.

See? That wasn't hard, was it?

[Kenny McCormack]

In article <ml94jr$nrq$1...@news.m-online.net>,

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
...

>This is a quite extreme, code-wise large, workaround. Since it also requires
>application code to change I fail to see what advantage it has compared to
>adding the 'print' statement as in my original posting. A similar doubt I'd
>have with the elsethread posted while-getline loop suggestion in the BEGIN
>clause.

It's a shame that you didn't see my post through the right lens.

The idea was to demonstrate that with a small change to the 'inplace.awk'
include file, you could get the functionality that I suggested - of being
able to turn the 'inplace' functionality on & off on a per-file basis.

Obviously, in the long run, you'd just fix the include file and then the
problem would be solved. You would, of course, be responsible for setting
the "do_inplace" variable yourself in your code, but that should be easy
enough done.

I just got carried away with the instant example, and chose to optimize the
code layout for that, but it should be clear that that's not it would be
done in a long-term, long-range solution.

--
"Every time Mitt opens his mouth, a swing state gets its wings."

(Should be on a bumper sticker)

[Kaz Kylheku]

The print statement means you are replacing the file with a new one which
you believe has the same contents. This may work in your given situation, but
is hardly a general substitute for not modifying the file at all.

A similar doubt I'd
> have with the elsethread posted while-getline loop suggestion in the BEGIN
> clause.
>
> Obviously I was too naively looking at the 'inplace' feature, assuming that
> it would just operate close to the (shell-) boundaries of the awk program.

It's impossible to implement what it does using a shell wrapper. Consider
a program invocation:

program file1 file2 file3

program opens the files one by one, reads them and produces output.

There is no way we can wrap this with temporary files and mv commands
so that the files are filtered in place. The reason is that the output is
catenated into a single destination (standard output).

Only code inside program can reliably do the inplace switch from one
file to the next.

>
> Meanwhile I also continued with ideas, one was to invoke a 'chmod -w map',
> i.e. making the map file read-only on file system level. Surprisingly gawk
> doesn't respect that flag and overwrites (or rather replaces) it as well.
> Doh! - This is hard. - No abort, not even a warning, and the file is gone.

To issue a warning would be to disagree with the design of the underlying
Unix operating system, in which the write permission on an object is
irrelevant for the purposes of removing that object from the directory
and creating another one with the same name.

If it is "bad" to be able to do that for a read-only object, that is a
system-level design problem with the operating system, and not specifically a
problem with the Awk inplace feature.

Other programs also have the "problem": for instance GNU patch happily patches
a read-only file (preserving the read-only permissions and everything).

$ ls -li foo
706596 -r--r--r-- 1 kaz kaz 54 Jun 10 07:12 foo
$ patch < foo.patch
patching file foo
$ ls -li foo
706861 -r--r--r-- 1 kaz kaz 101 Jun 10 07:13 foo

Also here is another issue: what if the file is a symbolic link? There are
two behaviors possible for inplace

- delete the symbolic link, and create a real file (GNU patch does this)
- leave the symlink, and delete/replace the original.

[Janis Papanagnou]

On 10.06.2015 14:21, Kenny McCormack wrote:
> In article <ml95bv$idq$1...@news.m-online.net>,
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 10.06.2015 08:59, Kenny McCormack wrote:
>>> In article <ml8jjj$e0u$1...@news.m-online.net>,
>>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> [...]
>>>>
>>>> My initial surprise stems from the fact that after that processing the map
>>>> file was empty! Then I realized that despite the file 'map' is only *read*
>>>> it will be emptied due to the 'inplace' function.
>>>
>> [...]
>>>
>>> In a way, it would be nice to be able to turn the 'inplace' magic on and
>>> off on a per-file basis. That is, to be able to say "Do the 'inplace'
>>> magic only for my 'main' file." Maybe some global flag, say, in
>>> PROCINFO[].
>>
>> Maybe yet easier if gawk would just respect the read-only flags of the
>> filesystem and not change such files. (Currently gawk silently ignores
>> the read-only flag and overwrites the file.)
>
> You gotta admit that both of the "solutions" you've proposed are klunky and
> weird.

Well, I'm not that sure as you seem to be. Given the actual logic - and you
made a strong statement upthread:

>> This is all working-as-designed. The point is that 'inplace' is some
>> powerful magic, and it fundamentally changes the way AWK works.

that means that I would have to consider re-designing my code, because it
does (against my expectation) not work just at the shell interface level.
The obvious and straightforward way to address that "changed logic" is to
add that 'print'.

The 'chmod' thing was actually just a try (behavioural analysis) that also
didn't work as I expected, and, as I noticed, is (whether sensible or not)
even documented behaviour in the GNU manual:
"[...] redirects standard output to a temporary file configured to have
the same owner and permissions as the original."

> Maybe effective, but, really, you want to "fix" this by changing
> file permissions to read-only?

Not really. Though if it would have worked I might have used it in those
rare cases where I'd have wanted a terse workaround. (OTOH, if it worked
it would probably be a saner behaviour of awk to abort with an error. I'm
yet undecided about the best behaviour here.)

> I mean, if you're gonna do that, you might
> as well just revert to the old way of using the shell to implement the
> "inplace" functionality.

Yes, this might indeed be an option in certain cases. Currently, though,
I have a situation where it doesn't fit well:

awk '...' one_mapfile tons-of-html-files-to-fix.html...

That means to rewrite all prints to print ... > FILENAME".new" and
shell looping over all files. Not very satisfying.

>
> (Or by adding a silly extra 'print' statement into your AWK code so that
> the "mapping" file gets overwritten every single time you run your script?)

(Actually that is the direct consequence of the new 'inplace' semantics.)


An observation that should not be dismissed in the given context is the
actual behaviour of all awks in case of a standard construct like:

cond { print > "file" }

Here the file will *not* be overwritten if the condition never matches
(or respectively the file not created if there was none existing before).

>
> My solution, of basically fixing the 'inplace.awk' include file, is on the
> right track. It only looked verbose the way I presented it because, for
> demonstration purposes, I included the code inline rather than that which
> is the right, long-term, solution - fixing the include file itself, so that
> the problem is fixed forevermore. See my next post/response for more
> detail on this, but note for now that the idea was to implement was I
> suggested in the paragraph above (the one that starts with "In a way...").

Thanks for your engagement! Appreciated.

Janis

[Janis Papanagnou]

On 10.06.2015 14:26, Kenny McCormack wrote:
> In article <ml94jr$nrq$1...@news.m-online.net>,
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> ...
>> This is a quite extreme, code-wise large, workaround. Since it also requires
>> application code to change I fail to see what advantage it has compared to
>> adding the 'print' statement as in my original posting. A similar doubt I'd
>> have with the elsethread posted while-getline loop suggestion in the BEGIN
>> clause.
>
> It's a shame that you didn't see my post through the right lens.

I'm sorry that I gave that impression.

But, frankly, relocating the logic

NR==FNR { map[$1] = $2;next }

to

!do_inplace { map[$1] = $2;next }

where do_inplace is elsewhere defined as ARGIND > 1 did not look appealing.
The original semantics of the "for the first file do" idiom has now been
morphed to a technical "inplace" based level WRT the file; the mapping is
depening on the actual file. To me that looked not right. (But maybe you
had some code structure in mind - you mentioned it elsewhere - that is not
yet apparent to me.)

>
> The idea was to demonstrate that with a small change to the 'inplace.awk'
> include file, you could get the functionality that I suggested - of being
> able to turn the 'inplace' functionality on & off on a per-file basis.
>
> Obviously, in the long run, you'd just fix the include file and then the
> problem would be solved. You would, of course, be responsible for setting
> the "do_inplace" variable yourself in your code, but that should be easy
> enough done.
>
> I just got carried away with the instant example, and chose to optimize the
> code layout for that, but it should be clear that that's not it would be
> done in a long-term, long-range solution.

Janis

[Janis Papanagnou]

On 10.06.2015 16:17, Kaz Kylheku wrote:
> On 2015-06-10, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>
> The print statement means you are replacing the file with a new one which
> you believe has the same contents. This may work in your given situation, but
> is hardly a general substitute for not modifying the file at all.

Yes. This is not what I like, but a consequence of how inplace is defined;
it operates on the input file, all output becomes the contents of the new
file version, and - arguably the right thing - even if nothing is written
the "null" file contents constitutes the new file. whether I substitute on
some/all original lines or (conditionally or not) at none, you need the
prints to create the new file. An unchanged file is only a special case;
the prints are necessary.

>
> A similar doubt I'd
>> have with the elsethread posted while-getline loop suggestion in the BEGIN
>> clause.
>>
>> Obviously I was too naively looking at the 'inplace' feature, assuming that
>> it would just operate close to the (shell-) boundaries of the awk program.
>
> It's impossible to implement what it does using a shell wrapper. Consider
> a program invocation:
>
> program file1 file2 file3
>
> program opens the files one by one, reads them and produces output.
>
> There is no way we can wrap this with temporary files and mv commands
> so that the files are filtered in place. The reason is that the output is
> catenated into a single destination (standard output).
>
> Only code inside program can reliably do the inplace switch from one
> file to the next.

Sure. Elsethread I explained what (unsatisfying) changes would be necessary.

>
>>
>> Meanwhile I also continued with ideas, one was to invoke a 'chmod -w map',
>> i.e. making the map file read-only on file system level. Surprisingly gawk
>> doesn't respect that flag and overwrites (or rather replaces) it as well.
>> Doh! - This is hard. - No abort, not even a warning, and the file is gone.
>
> To issue a warning would be to disagree with the design of the underlying
> Unix operating system, in which the write permission on an object is
> irrelevant for the purposes of removing that object from the directory
> and creating another one with the same name.

Good point. But from a conceptual view the file needs to be re-written, and
only the technical implementation (temporary file, deletion) explains the
observed behaviour.

>
> If it is "bad" to be able to do that for a read-only object, that is a
> system-level design problem with the operating system, and not specifically a
> problem with the Awk inplace feature.

I disagree here. I consider the awk tool an abstraction; the tool defines
how it behaves.

>
> Other programs also have the "problem": for instance GNU patch happily patches
> a read-only file (preserving the read-only permissions and everything).
>
> $ ls -li foo
> 706596 -r--r--r-- 1 kaz kaz 54 Jun 10 07:12 foo
> $ patch < foo.patch
> patching file foo
> $ ls -li foo
> 706861 -r--r--r-- 1 kaz kaz 101 Jun 10 07:13 foo
>
> Also here is another issue: what if the file is a symbolic link? There are
> two behaviors possible for inplace
>
> - delete the symbolic link, and create a real file (GNU patch does this)
> - leave the symlink, and delete/replace the original.

Janis

[Andrew Schorr]

Hi,

As discussed on the bug mailing list, I don't think playing around with file permissions is the right way to address this issue. The straightforward approach is to allow the user to control which files on the command-line are subject to "inplace" editing. The simple solution is to add a global inplace variable that defaults to 1 and controls whether inplace editing will be used on each file. If you don't want to use inplace editing on a file, then add "inplace=0" on the command line prior to that filename. Then you can later put inplace=1 to turn it back on. The revised version of inplace.awk looks like this:

# inplace --- load and invoke the inplace extension.

@load "inplace"

# 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.

# By default, each filename on the command line will be edited inplace.
# But you can selectively disable this by adding an inplace=0 argument
# prior to files that you do not want to process this way. You can then
# reenable it later on the commandline by putting inplace=1 before files
# that you wish to be subject to inplace editing.

# 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.

BEGIN {
inplace = 1 # enabled by default
}

BEGINFILE {
if (_inplace_filename != "")
inplace_end(_inplace_filename, INPLACE_SUFFIX)
if (inplace)
inplace_begin(_inplace_filename = FILENAME, INPLACE_SUFFIX)
else
_inplace_filename = ""
}

END {
if (_inplace_filename != "")
inplace_end(_inplace_filename, INPLACE_SUFFIX)
}


For this particular example, one would say:

gawk -i inplace '
NR==FNR { map[$1] = $2 ; next }
{ print map[$1] }
' inplace=0 map inplace=1 file1 file2

Does this seem like a good solution?

Note: Arnold suggested this solution. I had completely forgotten that one can place variable assignments between file arguments. I always use -v these days, but this is a nice use of the legacy behavior.

Regards,
Andy

[Kenny McCormack]

In article <52e5eba8-ad16-4f8a...@googlegroups.com>,

Andrew Schorr <asc...@telemetry-investments.com> wrote:
>As discussed on the bug mailing list, I don't think playing around with file
>permissions is the right way to address this issue.

Agreed. Nor should you have to code a "print" statement in, which will
re-write those files that you don't want to "inplace" every time you run
the script. Kaz has adequately demonstrated why this is a really bad idea.

>The straightforward approach is to allow the user to control which files
>on the command-line are subject to "inplace" editing.

Right. I had been planning on posting my idea of a solution for a few days
now, but you seem to have beaten me to it.

My idea, which is somewhat simpler, though more abstract, is to have an
array called "dont_inplace_me" (or whatever name we end up choosing) - on
the assumption that you are probably going to want to inplace most of the
files, but just not the first 1 (or more). In the simplest case, you just
have one "map" file, so you just have to tell it not to "inplace" that one
single file.

In code, my idea is:

# User-space code here
@include "inplace.awk"
BEGIN { dont_inplace_me[1] }
...

And then the operative code in "inplace.awk" is:

# System-space code here
if (!(ARGIND in dont_inplace_me))
... go ahead and inplace me

P.S. As I look on this now, I realize that this might not be quite as
easy/clear in a command line AWK program (invocation). My method certainly
looks better to me from a "script in a file" perspective, but I can see
that (in at least some people's minds) the primary use of 'inplace' is in
command line invocations, and in that context, assigning to an array might
be seen as too bulky.

Well, let the market decide...

--
"The God of the Old Testament is arguably the most unpleasant character
in all fiction: jealous and proud of it; a petty, unjust, unforgiving
control-freak; a vindictive, bloodthirsty ethnic cleanser; a misogynistic,
homophobic, racist, infanticidal, genocidal, filicidal, pestilential,
megalomaniacal, sadomasochistic, capriciously malevolent bully."

- Richard Dawkins, The God Delusion -

[Andrew Schorr]

On Sunday, June 14, 2015 at 4:48:47 PM UTC-4, Kenny McCormack wrote:
> P.S. As I look on this now, I realize that this might not be quite as
> easy/clear in a command line AWK program (invocation). My method certainly
> looks better to me from a "script in a file" perspective, but I can see
> that (in at least some people's minds) the primary use of 'inplace' is in
> command line invocations, and in that context, assigning to an array might
> be seen as too bulky.
>
> Well, let the market decide...

I think the idea is that inplace editing is for quick command-line hacks. As such, being able to control it simply on the command line makes most sense. I first considered several more heavyweight approaches, such as specifying a regexp for which files are subject to inplace editing or a user function to decide whether to edit the file inplace, but Arnold set me straight. I think the simple, elegant solution is to allow it to be controlled inline on the command line.

But maybe I'm overinvested because I already wrote the patch to the code and docs. If other folks feel that Arnold's solution is wrong, we can go back to the drawing board. That being said, the inplace extension is intended for quick hacks. I don't want to spend too much time on this.

Regards,
Andy

[Ed Morton]

What would sed do? Whatever it it, that's what awk should do.

Ed.

[Janis Papanagnou]

On 14.06.2015 21:46, Andrew Schorr wrote:
>
[...]

>
> For this particular example, one would say:
>
> gawk -i inplace '
> NR==FNR { map[$1] = $2 ; next }
> { print map[$1] }
> ' inplace=0 map inplace=1 file1 file2
>
> Does this seem like a good solution?

Yes, that's quite nice.

Janis

[Kenny McCormack]

In article <d3e8be73-3e6b-42de...@googlegroups.com>,

Andrew Schorr <asc...@telemetry-investments.com> wrote:
>On Sunday, June 14, 2015 at 4:48:47 PM UTC-4, Kenny McCormack wrote:
>> P.S. As I look on this now, I realize that this might not be quite as
>> easy/clear in a command line AWK program (invocation). My method certainly
>> looks better to me from a "script in a file" perspective, but I can see
>> that (in at least some people's minds) the primary use of 'inplace' is in
>> command line invocations, and in that context, assigning to an array might
>> be seen as too bulky.
>>
>> Well, let the market decide...
>
>I think the idea is that inplace editing is for quick command-line hacks. As
>such, being able to control it simply on the command line makes most sense. I
>first considered several more heavyweight approaches, such as specifying a regexp
>for which files are subject to inplace editing or a user function to decide
>whether to edit the file inplace, but Arnold set me straight. I think the
>simple, elegant solution is to allow it to be controlled inline on the command
>line.

OK. FWIW, my primary focus is on script-in-a-file, because the first time
I ever used 'inplace' was in that context.

But I realize now that given that the code in inplace.awk is so simple
(especially in 4.1.1; before it got complexed up in 4.1.3), the point is
that you might as well 'inline' it (i.e., copy the code from inplace.awk
into your own script and modify as necessary). I think that is what I will
do with my own script that uses 'inplace' - once I get a round tuit.

So, given that - that the writer of a script-in-a-file can always just
'inline' it - it makes sense for the system ('official') version to be
designed to make it as easy as possible for the command line user.

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[Andrew Schorr]

On Monday, June 15, 2015 at 1:31:20 AM UTC-4, Janis Papanagnou wrote:
> On 14.06.2015 21:46, Andrew Schorr wrote:
> >
> [...]
> >
> > For this particular example, one would say:
> >
> > gawk -i inplace '
> > NR==FNR { map[$1] = $2 ; next }
> > { print map[$1] }
> > ' inplace=0 map inplace=1 file1 file2
> >
> > Does this seem like a good solution?
>
> Yes, that's quite nice.

This change has been committed and will be in the next release. You can use the inplace.awk I posted above in the meantime.

Regards,
Andy

[Janis Papanagnou]

Thanks!

Janis

>
> Regards,
> Andy
>