All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	Koichi Murase <myoga.murase@gmail.com>
Cc: git@vger.kernel.org,
	"Justin Donnelly" <justinrdonnelly@gmail.com>,
	"Denton Liu" <liu.denton@gmail.com>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Edwin Kofler" <edwin@kofler.dev>
Subject: Re: [PATCH 1/2] completion: quote arguments of test and [
Date: Mon, 24 Apr 2023 07:43:09 -0600	[thread overview]
Message-ID: <6446876d2e22b_aba294a5@chronos.notmuch> (raw)
In-Reply-To: <xmqqh6ta3485.fsf@gitster.g>

Junio C Hamano wrote:
> Koichi Murase <myoga.murase@gmail.com> writes:
> 
> > The raw command substitutions $v in the arguments of the test command
> > and the [ command are subject to word splitting and pathname
> > expansions. Even when it is ensured that the variable is not empty and
> > does not contain whitespaces and glob characters, it can fail when IFS
> > is set to non-trivial values containing letters and digits.
> 
> The above sounded good before I looked at the patch, and it still is
> good in theory, but it start to look mostly academic especially with
> enclosing $# inside a pair of double-quotes, and the variable would
> have only digits.  The same for $i and $j that appear in the loop
> control "for ((i=0, j=0; ...)); do".  The story is pretty much the
> same for local variables we set outselves to signal our findings,
> like $pcmode that is only set to either 'yes' or 'no'.

I do have the same opinion.

Although the result seems more proper, I fail to see the actual value of doing
all these changes everywhere.

On the other hand I do see the very real harm that they would break the
git-completion branch everywhere. Rebasing those 50-so patches would not be
very pleasant.

> In other words, this patch looks way too noisy to be reviewed to
> discover its real worth.

Agreed.

-- 
Felipe Contreras

      parent reply	other threads:[~2023-04-24 13:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-20  7:46 [PATCH 1/2] completion: quote arguments of test and [ Koichi Murase
2023-04-20  7:46 ` [PATCH 2/2] completion: suppress unwanted unescaping of `read` Koichi Murase
2023-04-20 16:45   ` Junio C Hamano
2023-04-20 22:31     ` Koichi Murase
2023-04-20 22:38       ` [PATCH] " Koichi Murase
2023-04-20 22:47         ` Junio C Hamano
2023-04-24 13:52         ` Felipe Contreras
2023-04-20 16:31 ` [PATCH 1/2] completion: quote arguments of test and [ Junio C Hamano
2023-04-20 20:59   ` Koichi Murase
2023-04-24 13:43   ` Felipe Contreras [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6446876d2e22b_aba294a5@chronos.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=edwin@kofler.dev \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=justinrdonnelly@gmail.com \
    --cc=liu.denton@gmail.com \
    --cc=myoga.murase@gmail.com \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.