From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 970F31F4B4 for ; Mon, 7 Dec 2020 19:00:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726298AbgLGS4X (ORCPT ); Mon, 7 Dec 2020 13:56:23 -0500 Received: from cloud.peff.net ([104.130.231.41]:55174 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726207AbgLGS4X (ORCPT ); Mon, 7 Dec 2020 13:56:23 -0500 Received: (qmail 8909 invoked by uid 109); 7 Dec 2020 18:55:42 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Mon, 07 Dec 2020 18:55:42 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 25121 invoked by uid 111); 7 Dec 2020 18:55:42 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Mon, 07 Dec 2020 13:55:42 -0500 Authentication-Results: peff.net; auth=none Date: Mon, 7 Dec 2020 13:55:41 -0500 From: Jeff King To: Junio C Hamano Cc: Jan Engelhardt , git@vger.kernel.org Subject: Re: `git grep` is too picky about option parsing Message-ID: References: <704q5rs6-63q1-sp78-9845-227oq8q42o8q@vanv.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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