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
