git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Olsson John <john.olsson@saabgroup.com>
To: Kevin Daudt <me@ikke.info>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: RE: [EXTERNAL] Re: Error handling when giving empty command line arguments
Date: Wed, 25 May 2022 07:03:50 +0000	[thread overview]
Message-ID: <8940ab846c1a4b8385a4def64a905bc3@saabgroup.com> (raw)
In-Reply-To: <Yo2zfxP4hII+iwfb@alpha>

> You are running into this issue because you use "$(force}" instead of ${force}. In the latter case, if $force is empty, the shell will not pass an empty string as an argument to git.

Yes, I know. I'm so used to always expanding variables within double quotes to avoid word splitting. And it doesn't help that I'm using shellcheck together with flycheck in Emacs so it constantly nags me about the danger of expanding variables without using double quotes. ;)


> This does mean that it is subject to word splitting, but that can be an advantage as well if you decide you need more arguments than just '--force'. You should only use that in case you control what $force contains.

Yes, I agree with you here.

-----Original Message-----
From: Kevin Daudt <me@ikke.info> 
Sent: den 25 maj 2022 06:42
To: Olsson John <john.olsson@saabgroup.com>
Cc: git@vger.kernel.org
Subject: [EXTERNAL] Re: Error handling when giving empty command line arguments

On Tue, May 24, 2022 at 01:25:43PM +0000, Olsson John wrote:
> I have so far only seen this behavior with 'git fetch' command, but it might be more general depending on how command line parsing is implemented.
> 
> In a Bash script I had something similar to (but more complicated than 
> what I show below)
> 
>   git fetch "${force}"
> 
> where $force is either an empty string or '--force'. Due to that you 
> usually want to expand all variables within double quotes when writing 
> Bash scripts I did not realize that I had made a mistake here. Instead 
> I got this strange error message and spent a couple of hours chasing 
> it
> 
>   fatal: no path specified; see 'git help pull' for valid url syntax
> 
> This problem eventually turned out to be of the trivial kind once I realized why I got it, and also very simple to reproduce. Just do
>   $ git fetch ""
>   fatal: no path specified; see 'git help pull' for valid url syntax
>   $
> 
> That is, 'git fetch' does not check if the given string is an empty string before writing the error message. The empty string is completely unrelated to any path/URI and in this case it was not that helpful.
> 
> What do you say? Wouldn't it be better with a more specific error message when an option value/argument is an empty string? Or should perhaps empty strings be ignored by the git commands?
> 
> 
> /John
> 

Hello John,

You are running into this issue because you use "$(force}" instead of ${force}. In the latter case, if $force is empty, the shell will not pass an empty string as an argument to git.

This does mean that it is subject to word splitting, but that can be an advantage as well if you decide you need more arguments than just '--force'. You should only use that in case you control what $force contains.

Hope this helps,
Kevin

      reply	other threads:[~2022-05-25  7:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24 13:25 Error handling when giving empty command line arguments Olsson John
2022-05-24 22:51 ` Junio C Hamano
2022-05-25  7:32   ` [EXTERNAL] " Olsson John
2022-05-25 15:46     ` Junio C Hamano
2022-05-25  4:41 ` Kevin Daudt
2022-05-25  7:03   ` Olsson John [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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=8940ab846c1a4b8385a4def64a905bc3@saabgroup.com \
    --to=john.olsson@saabgroup.com \
    --cc=git@vger.kernel.org \
    --cc=me@ikke.info \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).