Re: `git grep` is too picky about option parsing

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

 



On Mon, Dec 07, 2020 at 10:46:58AM -0800, Junio C Hamano wrote:

> > Either of those would let "-amend" continue to be an error, but fix
> > "-lin".
> 
> I am wondering if a rule like "you cannot concatenate a short option
> that takes argument with other short options" work.  The problem
> with "-a -m end" is really that the 'm' takes arbitrary end-user
> input.  So "commit -ave" would be fine, but "commit -ame" would not
> be.  This would make both "-line foo" and "--linefoo" consistently
> invalid, but "-lin -e foo" is still OK and make the rule easier to
> explain.

Personally, I find "-linefoo" totally unreadable (and in general I find
the "stuck" form of short options with a string to be pretty ugly,
though I understand it is the recommended form to handle optional
arguments). But "-line foo" is not so horrible IMHO, and I think it
would be sad to lose it. (I don't use it with grep, but my standard perl
invocation is "perl -lpe 'some script'"; another common one is "tar xvf
foo.tar").

And it works now (obviously not in the case we're discussing, but in
other cases that don't run afoul of the typo fix), so I think people
would see that as a regression.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux