Hello Ed.
Ed:
I have a feeling this is [not] going to go down well but here goes: can we
change the existing un-released code to use some other letter for
extension functionality from "-i" to some other letter (I was going
to suggest the obvious "e" or "E" but I see they're already taken so
how about -x for eXtension?) and then use "-i" for "inplace"?
No.
Andy:
I don't actually agree with you about that. Currently, "-i" tells
gawk to "include" a source code file. And "-l" tells it to load
a shared library extension.
There are two new features in the development branch ("master" in the
git repo). -i means read an awk source file. It differs somewhat from -f,
and you can see the details in the gawk manual in that branch.
The -l option means load an extension. You can think of an extension as
being like a plugin in a browser - it's *binary* code loaded into the
gawk address space. Gawk is able to call into the extension and the
extension into gawk, using a defined C API.
The new features work best when used hand-in-hand. The manual has
some examples, and Andy's gawkextlib project on sourceforge (nee "xgawk")
provides the XML features as a combination of binary extensions and
awk library files. What's important is that the XML features require
no changes at all to the gawk main code base, whereas previously xgawk
was an actual fork of the gawk code.
These are fairly intuitive option names
that have been used for years by the xgawk approach. But I'll grant
that the installed base of code is pretty small, so if the community
thinks -i is better used for in-place, then so be it.
*I* don't think that -i is better for in-place, and in this instance,
I have the deciding vote. Sorry to be heavy handed about it, but
this discussion needs to come to a close.
That being said, there is still not a consensus that the in-place feature
should be added to the main gawk binary. There is no real point in
debating what option letter should be used for the feature unless we
first agree that the main binary needs to support in-place editing.
This is decided. I will not add it to the main gawk binary because it will
be a ton of code churn (spelled P-A-I-N) for ROI that can be achieved
in easier ways.
Given that this feature can be implemented in an extension, I think
there's a natural reluctance to incorporate it into the main gawk codebase.
Exactly. Since an extension, *considerably more easily*, can provide the
functionality, I am not going to make any changes to the mainline code base.
Period.
I can't find it now, but I believe, Ed, that you stated that you didn't
understand the difference between putting an in-place feature into the
main code base or doing it as an extension. Fair enough, but since that
is the case, you have to trust me when I say that there is a significant
difference, and that it really does matter.
And you asked, are we talking about shipping a wrapper script with
gawk to run 'gawk -i inplace script files...'. The answer there is
yes; if someone writes the C extension, the awk files to go with it,
the wrapper script and the documentation (and signs the paperwork if
s/he hasn't done so already), I'll include everything in the dist.
The gawk manual in the master branch explains how to write an extension;
the chapter on it is close to 50 pages, including examples. The bug-gawk
list archive contains enough discussion so that anyone with medium
C and Unix skills could write the extension, the awk files, and the
shell script.
Now someone in the community, who thinks this feature is worthwhile,
needs to step up to the plate and do the work.
Thanks,
Arnold