[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gawk] in-place edit request
From: |
Ed Morton |
Subject: |
Re: [bug-gawk] in-place edit request |
Date: |
Mon, 31 Dec 2012 12:29:50 -0600 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
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.
- Re: [bug-gawk] in-place edit request, (continued)
- Re: [bug-gawk] in-place edit request, Ed Morton, 2012/12/31
- Re: [bug-gawk] in-place edit request, arnold, 2012/12/31
- Re: [bug-gawk] in-place edit request, Ed Morton, 2012/12/31
- Re: [bug-gawk] in-place edit request, arnold, 2012/12/31
- Re: [bug-gawk] in-place edit request, Ed Morton, 2012/12/31
- Re: [bug-gawk] in-place edit request, Andrew J. Schorr, 2012/12/31
- Re: [bug-gawk] in-place edit request, Ed Morton, 2012/12/31
- Re: [bug-gawk] in-place edit request, Andrew J. Schorr, 2012/12/31
- Re: [bug-gawk] in-place edit request, Ed Morton, 2012/12/31
- Re: [bug-gawk] in-place edit request, Andrew J. Schorr, 2012/12/31
- Re: [bug-gawk] in-place edit request,
Ed Morton <=
- Re: [bug-gawk] in-place edit request, Aharon Robbins, 2012/12/31
- Re: [bug-gawk] in-place edit request, Ed Morton, 2012/12/31
- Re: [bug-gawk] in-place edit request, Manuel Collado, 2012/12/31
- Re: [bug-gawk] in-place edit request, j . eh, 2012/12/23
- Re: [bug-gawk] in-place edit request, Andrew J. Schorr, 2012/12/23
- Re: [bug-gawk] in-place edit request, Andrew J. Schorr, 2012/12/23
- Re: [bug-gawk] in-place edit request, Aharon Robbins, 2012/12/25
- Re: [bug-gawk] in-place edit request, Assaf Gordon, 2012/12/25
- Re: [bug-gawk] in-place edit request, Andrew J. Schorr, 2012/12/26
- Re: [bug-gawk] in-place edit request, Andrew J. Schorr, 2012/12/26