coreutils
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]