[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cut enhancement: -C as short option for --complement
From: |
Jim Meyering |
Subject: |
Re: cut enhancement: -C as short option for --complement |
Date: |
Thu, 05 Apr 2012 22:54:31 +0200 |
Mark Krenz wrote:
> On Thu, Apr 05, 2012 at 05:08:23PM GMT, Jim Meyering
> [address@hidden] said the following:
>>
>> Did you know that --co is an acceptable abbreviation for --complement?
>
> Actually I didn't know you can do this with programs that use getopts.
> Do you happen to know where is this documented?
Sure. "man 3 getopt_long"
getopt_long() and getopt_long_only()
The getopt_long() function works like getopt() except that it also
accepts long options, started with two dashes. (If the program accepts
only long options, then optstring should be specified as an empty
string (""), not NULL.) Long option names may be abbreviated if the
abbreviation is unique or is an exact match for some defined option.
> I also feel like relying on this behavior can be a bad thing.
It is a good thing ;-)
> Eventually another option may come along and all the people who are used
If we were adding options frequently and/or blindly,
you might have a point, but we're well aware of the issues
and add new options infrequently. When we do, we take care
not to impinge on existing abbreviations.
> to typing --co will suddenly need to use another character or two. Then
> eventually you might as well just type in the whole option anyways.
With a decent shell, you can type cut --co<TAB>, and it will type
the rest, completing that to "--complement". If some day we add
another long-named option whose name starts with --co, when you hit
TAB, your shell will display the two remaining choices and you'll
have to type at least one more letter to select the one you want.
If you're using a script, just type out the full name, both for
readability and for future-portability.
>> We try to avoid adding new short-named options unless there is a
>> very compelling reason.
>
> I understand this stance and agree with it in many cases due to the
> overpolluted option namespaces you see in some programs. However it
> seems harmless enough in the case of the cut command, which has only a
> few options and also already has the complement functionality, but
> simply has no short option for it.
>
> Lots of programs have modes where they do the reverse of what they
> normally do by default (grep -v for instance). I would think that a
> short option for reversing cuts default operation would be a welcome
> addition for many people. So I think that's a pretty compelling reason
> to add a short option for it and save even more typing.
If we were to accept this sort of argument, ls would
have run out of option letters a couple of decades ago. Sorry.
- cut enhancement: -C as short option for --complement, Mark Krenz, 2012/04/05
- Re: cut enhancement: -C as short option for --complement, Jim Meyering, 2012/04/06
- Re: cut enhancement: -C as short option for --complement, Mark Krenz, 2012/04/05
- Re: cut enhancement: -C as short option for --complement,
Jim Meyering <=
- Re: cut enhancement: -C as short option for --complement, Mark Krenz, 2012/04/05
- Re: cut enhancement: -C as short option for --complement, Eric Blake, 2012/04/05
- Re: cut enhancement: -C as short option for --complement, Mark Krenz, 2012/04/05
- Re: cut enhancement: -C as short option for --complement, Eric Blake, 2012/04/05
- Re: cut enhancement: -C as short option for --complement, Mark Krenz, 2012/04/05