{"thread":{"id":"57918","subject":"Error handling when giving empty command line arguments","startedAt":"2022-05-24T14:07:53Z","lastAt":"2022-05-25T15:46:21Z","messageCount":6,"participants":["Olsson John","Junio C Hamano","Kevin Daudt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"455903","messageId":"dc08a8ee5ed64850872fd6529d1462e1@saabgroup.com","threadId":"57918","inReplyTo":null,"subject":"Error handling when giving empty command line arguments","fromName":"Olsson John","fromEmail":"john.olsson@saabgroup.com","sentAt":"2022-05-24T13:25:43Z","receivedAt":"2022-05-24T14:07:53Z","isPatch":false,"sender":{"key":"john.olsson@saabgroup.com","avatar":null},"body":"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.\n\nIn a Bash script I had something similar to (but more complicated than what I show below)\n\n  git fetch \"${force}\"\n\nwhere $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\n\n  fatal: no path specified; see 'git help pull' for valid url syntax\n\nThis 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\n  $ git fetch \"\"\n  fatal: no path specified; see 'git help pull' for valid url syntax\n  $\n\nThat 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.\n\nWhat 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?\n\n\n/John\n\n"},{"id":"455984","messageId":"xmqq35gyee7r.fsf@gitster.g","threadId":"57918","inReplyTo":"dc08a8ee5ed64850872fd6529d1462e1@saabgroup.com","subject":"Re: Error handling when giving empty command line arguments","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-24T22:51:52Z","receivedAt":"2022-05-24T22:51:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Olsson John <john.olsson@saabgroup.com> writes:\n\n>   git fetch \"${force}\"\n> ...\n>   $ git fetch \"\"\n>   fatal: no path specified; see 'git help pull' for valid url syntax\n>   $\n> ...\n> That is, 'git fetch' does not check if the given string is an\n> empty string before writing the error message. The empty string is\n> completely unrelated to any path/URI and in this case it was not\n> that helpful.\n\nThe user is not giving enough information to Git to allow it to tell\nif \"git fetch ''\" it got came from any of these with unset variable:\n\n\t$ git fetch \"$path\"\n\t$ git fetch \"$url\"\n\t$ git fetch \"$force\"\n\nbecause all Git sees is an empty string.\n\nIt is unfair to complain \"is completely unrelated\".  The user didn't\ngive enough information to even allow Git to tell if it is or is not\nrelated.\n\nThe message _is_ complaining about a malformed URL.  You can fetch\nfrom a local repository by specifying the path to the directory, or\nyou can fetch from a remote repository by specifying a URL.  Since\n\"\" turns out to be neither a valid path or URL, the message hints\nthat it didn't see any path or valid url on the command line.  This\nis coming from connect.c::parse_connect_url() that does not know\nwhich end-user facing command ended up reaching there, so it is\nunderstandable that it picked a command that ought to be more\nfamiliar to users, i.e. \"pull\".  FWIW, \n\n\t$ git ls-remote \"\"\n\nwould also give the same message that refers to \"git help pull\".\n\nBy the way, the \"fatal\" message talks about 'git help pull'; I\nwonder if it should say \"git help fetch\" instead, although they will\nrefer to the same text included from Documentation/urls.txt.\n\nThanks.\n"},{"id":"455998","messageId":"Yo2zfxP4hII+iwfb@alpha","threadId":"57918","inReplyTo":"dc08a8ee5ed64850872fd6529d1462e1@saabgroup.com","subject":"Re: Error handling when giving empty command line arguments","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2022-05-25T04:41:35Z","receivedAt":"2022-05-25T04:49:56Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Tue, May 24, 2022 at 01:25:43PM +0000, Olsson John wrote:\n> 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.\n> \n> In a Bash script I had something similar to (but more complicated than what I show below)\n> \n>   git fetch \"${force}\"\n> \n> 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\n> \n>   fatal: no path specified; see 'git help pull' for valid url syntax\n> \n> 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\n>   $ git fetch \"\"\n>   fatal: no path specified; see 'git help pull' for valid url syntax\n>   $\n> \n> 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.\n> \n> 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?\n> \n> \n> /John\n> \n\nHello John,\n\nYou are running into this issue because you use \"$(force}\" instead of\n${force}. In the latter case, if $force is empty, the shell will not\npass an empty string as an argument to git.\n\nThis does mean that it is subject to word splitting, but that can be an\nadvantage as well if you decide you need more arguments than just\n'--force'. You should only use that in case you control what $force\ncontains.\n\nHope this helps, \nKevin\n"},{"id":"456001","messageId":"8940ab846c1a4b8385a4def64a905bc3@saabgroup.com","threadId":"57918","inReplyTo":"Yo2zfxP4hII+iwfb@alpha","subject":"RE: [EXTERNAL] Re: Error handling when giving empty command line arguments","fromName":"Olsson John","fromEmail":"john.olsson@saabgroup.com","sentAt":"2022-05-25T07:03:50Z","receivedAt":"2022-05-25T07:13:58Z","isPatch":false,"sender":{"key":"john.olsson@saabgroup.com","avatar":null},"body":"> 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.\n\nYes, 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. ;)\n\n\n> 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.\n\nYes, I agree with you here.\n\n-----Original Message-----\nFrom: Kevin Daudt <me@ikke.info> \nSent: den 25 maj 2022 06:42\nTo: Olsson John <john.olsson@saabgroup.com>\nCc: git@vger.kernel.org\nSubject: [EXTERNAL] Re: Error handling when giving empty command line arguments\n\nOn Tue, May 24, 2022 at 01:25:43PM +0000, Olsson John wrote:\n> 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.\n> \n> In a Bash script I had something similar to (but more complicated than \n> what I show below)\n> \n>   git fetch \"${force}\"\n> \n> where $force is either an empty string or '--force'. Due to that you \n> usually want to expand all variables within double quotes when writing \n> Bash scripts I did not realize that I had made a mistake here. Instead \n> I got this strange error message and spent a couple of hours chasing \n> it\n> \n>   fatal: no path specified; see 'git help pull' for valid url syntax\n> \n> 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\n>   $ git fetch \"\"\n>   fatal: no path specified; see 'git help pull' for valid url syntax\n>   $\n> \n> 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.\n> \n> 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?\n> \n> \n> /John\n> \n\nHello John,\n\nYou 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.\n\nThis 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.\n\nHope this helps,\nKevin\n"},{"id":"456002","messageId":"8767dbe0c22540a4ab3e18684aa7e030@saabgroup.com","threadId":"57918","inReplyTo":"xmqq35gyee7r.fsf@gitster.g","subject":"RE: [EXTERNAL] Re: Error handling when giving empty command line arguments","fromName":"Olsson John","fromEmail":"john.olsson@saabgroup.com","sentAt":"2022-05-25T07:32:18Z","receivedAt":"2022-05-25T07:32:50Z","isPatch":false,"sender":{"key":"john.olsson@saabgroup.com","avatar":null},"body":"> The user is not giving enough information to Git to allow it to tell if \"git fetch ''\" it got came from any of these with unset variable:\n>\n>\t$ git fetch \"$path\"\n>\t$ git fetch \"$url\"\n>\t$ git fetch \"$force\"\n>\n> because all Git sees is an empty string.\n>\n> It is unfair to complain \"is completely unrelated\".  The user didn't give enough information to even allow Git to tell if it is or is not related.\n\nThat is exactly my point! I was thinking along the lines that perhaps the Git command(s) could complain about that it got an empty string as an argument since that is probably a mistake by the user due to that an empty string is neither a path, a URL/URI, or an option. It is thus an error case of its own.\n\n\nThe git checkout command actually complains about the case when you give it an empty string\n\n$ git checkout \"\" feature/foobar\nfatal: empty string is not a valid pathspec. please use . instead if you want to match all paths\n\n\nWhen it comes to git fetch it could assume that the given empty string is either a path or a URL/URI and write a similar error message. For instance\n\n$ git fetch \"\"\nfatal: empty string is not a valid pathspec or URL; see 'git help fetch' for valid syntax\n\nFor me there is an important distinction between \"no path specified\" and \"empty string\". The former says that an argument is missing and the latter says that an argument is indeed given but it is an empty string.\n\n"},{"id":"456101","messageId":"xmqqy1ypaa4d.fsf@gitster.g","threadId":"57918","inReplyTo":"8767dbe0c22540a4ab3e18684aa7e030@saabgroup.com","subject":"Re: [EXTERNAL] Re: Error handling when giving empty command line arguments","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-25T15:46:10Z","receivedAt":"2022-05-25T15:46:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Olsson John <john.olsson@saabgroup.com> writes:\n\n> The git checkout command actually complains about the case when\n> you give it an empty string\n>\n> $ git checkout \"\" feature/foobar\n> fatal: empty string is not a valid pathspec. please use . instead if you want to match all paths\n\nI actually knew that somebody new will bring up the message from\n\"checkout\", which special cases an empty parameter.\n\nThe reason why it gives an extra piece of guidance in this case is\nnot because an empty string is something that can often come from a\ncommon mistake, like the \"unset-variable-in-double-quotes\" example\nthat started this thread.\n\nAn empty string as a pathspec element used to mean \"everything in\nthe directory\", but we deprecated that interpretation of an empty\nstring, and then turned it into an error when somebody tried to use\nit.  And that is why there is such a special case message.  The\npurpose of it is primarily to help those who learned Git in older\ndays and thought we still took \"\" as if it were \".\".  \n\nSo we do not give the same error message if you say\n\n    $ git checkout \"no-such-file\" feature/foobar\n\nwhen there is no \"no-such-file\".  \"\" _is_ special in that case, and\nthat is why we special case.  For most other commands, it is not a\ngood model to follow.\n\n\"git fetch\", \"git pull\", \"git ls-remote\" never took an initial empty\nargument as something special that we later robbed its meaning and\nturned into an error.\n\nThanks.\n"}]}