Re: [bug-gawk] in-place edit request

[Ed Morton]

Andy -

On 12/31/2012 11:54 AM, Andrew J. Schorr wrote:
> Hi Ed,
>
> On Mon, Dec 31, 2012 at 11:44:41AM -0600, Ed Morton wrote:
> > I have a feeling this is 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"?
> I don't actually agree with you about that.  Currently, "-i" tells
> gawk to "include" a source code file.
But then you could argue that "-i" is the right name for including headers or 
including script files or including paths to search or including dictionaries or 
including modules or including absolutely anything else. "Including" is what  
you're doing not what functionality you are providing. Option names should 
reflect the functionality being provided by that option not the mechanism by 
which the functionality is provided. So "-i" is a poor choice for invoking 
extension functionality IMHO.

>    And "-l" tells it to load
> a shared library extension.
Hopefully the "l" stands for "library" rather than "load" as "load" is about as 
generic a name as "include" - you could "load" or "include" libraries or 
archives or options or anything else.
>    These are fairly intuitive option names
> that have been used for years by the xgawk approach.
Again IMHO they aren't intuitive but if people are used to it by now and have 
some sense of the semantic difference in gawk between "include" and "load", I 
understand....
>    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.
>
> 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.
Since I'm not familiar with the gawk code I don't fully understand the 
distinction, I'm really just focused on how thousands of people are going to be 
using it for the next 20+ years.
> >  From a user perspective "-i" is no better than any other letter for
> > extensions but "gawk -i" is a much better choice than "gawk -i
> > inplace" for in-place editing since all other tools use "-i" so it's
> > exactly what users would expect.
> >
> > I know it's more work but this stuff, once it's out there, will be
> > around for a VERY long time and used by VERY many people and this is
> > our one chance to get it right from a user perspective.
> I think you first need to make the case that in-place editing belongs
> in the main gawk binary.  We can then debate the proper allocation of option
> letters.  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.
I can see that from this email exchange. Again, I don't understand why it makes 
a difference but I accept that it does.
> The point of the extension mechanism is to enable developers to add new
> capabilities without having to patch the main gawk code.

OK but I don't see why that means I HAVE to invoke "extensions" by using "-i 
<extension_name>". Why can't we have a new direct gawk option to invoke the 
functionality provided by that "extension" if we think it's an extension that 
many people will use? That's rhetorical, I suppose, since it sounds like the way 
extensions are implemented in gawk requires that they be invoked through "-i 
<extension_name>".

>    I'm still not
> convinced that an "awk-i" wrapper script isn't adequate.  Why isn't that
> good enough?
Are you suggesting that the gawk development team provide a tool named "awk-i" 
that's distributed with gawk and that users can then invoke instead of "gawk -i 
inplace" or that users would all write their own "awk-i" tools or something else?

In any case, this is the clear, obvious, expected, ideal solution from a user 
perspective:

    sed -i 'script' file
    perl -i 'script' file
    ruby -i 'script' file
    awk -i 'script' file

Anything else is a compromise and SO many people for SO many years are going to 
be impacted, of course I'm going to advocate strongly for the ideal solution.

    Ed.