[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cut enhancement: -C as short option for --complement

From: Eric Blake
Subject: Re: cut enhancement: -C as short option for --complement
Date: Thu, 05 Apr 2012 15:48:15 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 04/05/2012 03:29 PM, Mark Krenz wrote:
> On Thu, Apr 05, 2012 at 09:15:12PM GMT, Eric Blake address@hidden said the 
> following:
>> The _easiest_ way to justify a short option letter is by reference to
>> another implementation that has the same semantics, and use that letter.
>>  Another road to this would be proposing the feature for inclusion into
>> POSIX, and picking a letter as part of your proposal (since POSIX will
>> only standardize on short names, not --complement); if the feature is
>> deemed useful enough to standardize, you've managed to pick a short letter.
>> In other words, it's not the choice of -C that we're worried about, it's
>> the fact that you're even proposing a short option in the first place
>> without providing compelling evidence that it is widely used or picked
>> up by other implementations.
>  Ok, thanks for explaining this. I think I understand now. You're
> worried that by choosing an option not in POSIX that it would be in
> conflict with any future choice made in POSIX. That makes sense.

You got it!  Since long options are explicitly guaranteed to never
conflict with POSIX, we have a strong tendency to favor only a long
option until proven that a short option makes sense.

>  Do you have any insight on submitting changes to the POSIX standards?
> will let anyone submit a
feature proposal, although it probably helps to look at existing reports
to get a good idea of what it might take to make a successful feature

Here's a recent attempt by someone to standardize 'sed -i' for in-place
editing, along with some feedback that in that particular case, the
POSIX folks would be a bit happier inventing a new option 'sed -I' that
doesn't suffer from minor compatibility differences between existing -i

Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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