{"thread":{"id":"29582","subject":"A note on modern git plus ancient meld (\"wrong number of arguments\")","startedAt":"2012-02-09T19:17:43Z","lastAt":"2012-02-10T22:30:09Z","messageCount":9,"participants":["Jeff Epler","David Aguilar","Jonathan Nieder","Sebastian Schuberth","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"184253","messageId":"20120209191742.GA20703@unpythonic.net","threadId":"29582","inReplyTo":null,"subject":"A note on modern git plus ancient meld (\"wrong number of arguments\")","fromName":"Jeff Epler","fromEmail":"jepler@unpythonic.net","sentAt":"2012-02-09T19:17:43Z","receivedAt":"2012-02-09T19:17:43Z","isPatch":false,"sender":{"key":"jepler@unpythonic.net","avatar":"https://avatars.githubusercontent.com/u/1517291?v=4"},"body":"I note this just in case it helps someone else track down a similar\nproblem, not because I think any change needs to be made to git, as a\nversion of meld new enough to not be affected by this problem is 5 years\nold.\n\nAt $DAYJOB, I recently encountered a problem after upgrading from (don't\nlaugh) git 1.7.1 to 1.7.8.3: one developer stated that meld failed to\nrun, instead displaying the error 'Wrong number of arguments (Got 5)'. \n\nWe determined that this user was running a very old version of meld\n(1.1.1) from his home directory, as opposed to the also very old system\nversion of meld (1.1.5). It turns out that the check added in \n f61bd9c mergetools/meld: Use '--output' when available\nfails on meld 1.1.1, leading git to incorrectly believe the --output\nflag is supporrted:\n $ meld-1.1.1 --output /dev/null --help >/dev/null 2>&1; echo $?\n 0 # i.e., detected as supported\nThe test as written gives the correct (\"not supported\") result with meld\n1.1.5:\n $ meld-1.1.5 --output /dev/null --help >/dev/null 2>&1; echo $?\n 2 # i.e., detected as supported\n\nso if you encounter the message 'Wrong number of arguments (Got 5)' from\nmeld, then check whether you have an ancient version of meld. If for\nsome reason you can't upgrade to at least 1.1.5, maybe you'd find the\nfollowing configuration flags useful:\n [merge]\n tool = ancientmeld\n [mergetool \"ancientmeld\"]\n cmd = meld-1.1.1 \\\"$LOCAL\\\" \\\"$MERGED\\\" \\\"$REMOTE\\\"\n\nJeff\n"},{"id":"184317","messageId":"CAJDDKr58LV9EDJZP+3S0YfyTOXFgJWD6nm=AiA19MkyBF-wb_g@mail.gmail.com","threadId":"29582","inReplyTo":"20120209191742.GA20703@unpythonic.net","subject":"Re: A note on modern git plus ancient meld (\"wrong number of arguments\")","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2012-02-10T02:42:51Z","receivedAt":"2012-02-10T02:42:51Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Thu, Feb 9, 2012 at 11:17 AM, Jeff Epler wrote:\n> I note this just in case it helps someone else track down a similar\n> problem, not because I think any change needs to be made to git, as a\n> version of meld new enough to not be affected by this problem is 5 years\n> old.\n>\n> At $DAYJOB, I recently encountered a problem after upgrading from (don't\n> laugh) git 1.7.1 to 1.7.8.3: one developer stated that meld failed to\n> run, instead displaying the error 'Wrong number of arguments (Got 5)'.\n>\n> We determined that this user was running a very old version of meld\n> (1.1.1) from his home directory, as opposed to the also very old system\n> version of meld (1.1.5).  It turns out that the check added in\n>    f61bd9c mergetools/meld: Use '--output' when available\n> fails on meld 1.1.1, leading git to incorrectly believe the --output\n> flag is supporrted:\n>    $ meld-1.1.1 --output /dev/null --help >/dev/null 2>&1; echo $?\n>    0   # i.e., detected as supported\n> The test as written gives the correct (\"not supported\") result with meld\n> 1.1.5:\n>    $ meld-1.1.5 --output /dev/null --help >/dev/null 2>&1; echo $?\n>    2   # i.e., detected as supported\n>\n> so if you encounter the message 'Wrong number of arguments (Got 5)' from\n> meld, then check whether you have an ancient version of meld.  If for\n> some reason you can't upgrade to at least 1.1.5, maybe you'd find the\n> following configuration flags useful:\n>    [merge]\n>        tool = ancientmeld\n>    [mergetool \"ancientmeld\"]\n>        cmd = meld-1.1.1 \\\"$LOCAL\\\" \\\"$MERGED\\\" \\\"$REMOTE\\\"\n\nWe originally used the --output test so that we wouldn't have to check\nfor a specific version. Does your meld support `meld --version`, and\nwhat does it output?\n\nI'm thinking that maybe we should just try and parse the version\nnumber since it seems like we cannot depend on ancient meld's return\ncode.\n\nThanks Jeff. I'll see what we can do about it.\n-- \nDavid\n"},{"id":"184330","messageId":"20120210082106.GA7871@burratino","threadId":"29582","inReplyTo":"CAJDDKr58LV9EDJZP+3S0YfyTOXFgJWD6nm=AiA19MkyBF-wb_g@mail.gmail.com","subject":"Re: A note on modern git plus ancient meld (\"wrong number of arguments\")","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-10T08:23:49Z","receivedAt":"2012-02-10T08:23:49Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"David Aguilar wrote:\n> On Thu, Feb 9, 2012 at 11:17 AM, Jeff Epler wrote:\n\n>> At $DAYJOB, I recently encountered a problem after upgrading from (don't\n>> laugh) git 1.7.1 to 1.7.8.3: one developer stated that meld failed to\n>> run, instead displaying the error 'Wrong number of arguments (Got 5)'.\n>>\n>> We determined that this user was running a very old version of meld\n>> (1.1.1) from his home directory, as opposed to the also very old system\n>> version of meld (1.1.5).\n[...]\n> We originally used the --output test so that we wouldn't have to check\n> for a specific version.\n\nMy bad. How about something like this patch (untested)?\n\n-- >8 --\nSubject: mergetools/meld: Use version number to detect '--output' support\n\nIn v1.7.7-rc0~3^2 (2011-08-19), git mergetool's \"meld\" support learned\nto use the --output option when calling versions of meld (1.5.0 and\nlater) that support it.\n\nAlas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as\nsupporting the option, so on systems with such meld, instead of\ngetting a nice merge helper, the operator gets a dialog box with the\ntext \"Wrong number of arguments (Got 5)\". (Version 1.1.5 is when meld\nswitched to using optparse. One consequence of that change was that\nerrors in usage are detected and signalled through the exit status\neven when --help was passed.)\n\nJust parse version numbers instead. We can detect the version number\nby running \"meld --version\" and postprocessing it. As a\nfutureproofing measure, we are careful to handle all three --version\noutput formats encountered so far. When confused, the mergetool falls\nback to assuming the --output option is not usable.\n\n - [0.1, 0.8.5): \"GNOME Meld 0.1\".\n - [0.8.5, 0.9.4.1):\n \"Meld 0.8.5\n Written by Stephen Kennedy \"\n - [0.9.4.1, 1.1.3): \"GNOME Meld 0.9.4.1\" again.\n - [1.1.3, 1.1.5): back to the two-line form.\n - [1.1.5, present): \"$0 1.1.5\". ($0 is typically \"meld\".)\n\nReported-by: Jeff Epler \nSigned-off-by: Jonathan Nieder \n---\n mergetools/meld | 17 +++++++++++------\n 1 files changed, 11 insertions(+), 6 deletions(-)\n\ndiff --git a/mergetools/meld b/mergetools/meld\nindex eaa115cc..3de29629 100644\n--- a/mergetools/meld\n+++ b/mergetools/meld\n@@ -23,10 +23,15 @@ check_meld_for_output_version () {\n \tmeld_path=\"$(git config mergetool.meld.path)\"\n \tmeld_path=\"${meld_path:-meld}\"\n \n-\tif \"$meld_path\" --output /dev/null --help >/dev/null 2>&1\n-\tthen\n-\t\tmeld_has_output_option=true\n-\telse\n-\t\tmeld_has_output_option=false\n-\tfi\n+\t# \"GNOME Meld 0.8.4\" -> \"0.8.4\"\n+\tmeld_version=$(\"$meld_path\" --version 2>/dev/null)\n+\tmeld_version=${meld_version#GNOME }\n+\tmeld_version=${meld_version#* }\n+\n+\tcase $meld_version in\n+\t[2-9].* | [1-9][0-9]* | 1.[5-9]* | 1.[1-9][0-9]*)\t# >= 1.5.0\n+\t\tmeld_has_output_option=true ;;\n+\t*)\n+\t\tmeld_has_output_option=false ;;\n+\tesac\n }\n-- \n1.7.9\n"},{"id":"184345","messageId":"CAHGBnuPBDO=tnoDFGOcGz4nZh9O_A803STmj7KALLuhwgf=hCg@mail.gmail.com","threadId":"29582","inReplyTo":"20120210082106.GA7871@burratino","subject":"Re: A note on modern git plus ancient meld (\"wrong number of arguments\")","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2012-02-10T11:29:10Z","receivedAt":"2012-02-10T11:29:10Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Fri, Feb 10, 2012 at 09:23, Jonathan Nieder wrote:\n\n> +       meld_version=${meld_version#GNOME }\n> +       meld_version=${meld_version#* }\n\nHmm, I might be mistaken, but aren't these string operations\nBash-only? And AFAIK Git is striving for standard sh compatibility ...\n\n-- \nSebastian Schuberth\n"},{"id":"184371","messageId":"20120210175915.GB19216@burratino","threadId":"29582","inReplyTo":"CAHGBnuPBDO=tnoDFGOcGz4nZh9O_A803STmj7KALLuhwgf=hCg@mail.gmail.com","subject":"Re: A note on modern git plus ancient meld (\"wrong number of arguments\")","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-10T17:59:15Z","receivedAt":"2012-02-10T17:59:15Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nSebastian Schuberth wrote:\n> On Fri, Feb 10, 2012 at 09:23, Jonathan Nieder wrote:\n\n>> +       meld_version=${meld_version#GNOME }\n>> +       meld_version=${meld_version#* }\n>\n> Hmm, I might be mistaken, but aren't these string operations\n> Bash-only? And AFAIK Git is striving for standard sh compatibility ...\n\nThey are widely supported in POSIX-style shells. See [1] and\nDocumentation/CodingGuidelines:\n\n - We use POSIX compliant parameter substitutions and avoid bashisms;\n namely:\n\n - We use ${parameter-word} and its [-=?+] siblings, and their\n colon'ed \"unset or null\" form.\n\n - We use ${parameter#word} and its [#%] siblings, and their\n doubled \"longest matching\" form.\n\nA good way to catch these things is to try with dash or posh, which\nare a little less full-featured than bash and ksh.\n\nThanks for looking it over.\nJonathan\n\n[1] http://pubs.opengroup.org/onlinepubs/9699919799/\nSearch for \"sh -\".\n"},{"id":"184399","messageId":"7vwr7unzs8.fsf@alter.siamese.dyndns.org","threadId":"29582","inReplyTo":"20120210082106.GA7871@burratino","subject":"Re: A note on modern git plus ancient meld (\"wrong number of arguments\")","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-10T21:28:55Z","receivedAt":"2012-02-10T21:28:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Just parse version numbers instead. We can detect the version number\n> by running \"meld --version\" and postprocessing it.\n\nHmm. I am debating myself if it may be more efficient, less error prone\nand simpler for the users if we gave them \"mergetool.meld.useOutput\"\nconfiguration option to tweak.\n\nWhen an older meld fails when given --output for real (not with the dry\nrun current code tries with --help), can we sanely detect that particular\nfailure? If we can do so, another possibility may be to do something like\nthis:\n\nmerge_cmd () {\n\tmeld_has_output_option=$(git config --bool mergetool.meld.useOutput)\n\tcase \"$meld_has_output_option\" in\n false)\n\t\t... do the non-output thing ...\n\t\t;;\n\ttrue)\n\t\t\"$merge_tool_path\" --output \"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"\n\t\t;;\n\t*)\n\t\t\"$merge_tool_path\" --output \"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"\n\t\tif it failed due to missing --output support?\n\t\tthen\n\t\t\tmeld_has_output_option=no\n git config mergetool.meld.useOutput false\n\t\t\tmerge_cmd\n\t\tfi\n ;;\n\tesac\n}\n"},{"id":"184408","messageId":"20120210215755.GL19216@burratino","threadId":"29582","inReplyTo":"7vwr7unzs8.fsf@alter.siamese.dyndns.org","subject":"[PATCH] mergetools/meld: Use --help output to detect --output support","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-10T21:57:55Z","receivedAt":"2012-02-10T21:57:55Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's \"meld\" support learned\nto use the --output option when calling versions of meld that are\ndetected to support it (1.5.0 and newer, hopefully).\n\nAlas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as\nsupporting the option, so on systems with such meld, instead of\ngetting a nice merge helper, the operator gets a dialog box with the\ntext \"Wrong number of arguments (Got 5)\". (Version 1.1.5 is when meld\nswitched to using optparse. One consequence of that change was that\nerrors in usage are detected and signalled through the exit status\neven when --help was passed.)\n\nLuckily there is a simpler check that is more reliable: the usage\nstring printed by \"meld --help\" reliably reflects whether --output is\nsupported in a given version. Use it.\n\nReported-by: Jeff Epler \nSigned-off-by: Jonathan Nieder \n---\nJunio C Hamano wrote:\n\n> When an older meld fails when given --output for real (not with the dry\n> run current code tries with --help), can we sanely detect that particular\n> failure?\n\nUnfortunately it just pops up a GUI with a modal dialog box like this:\n\t ___________________________________\n\t| |\n\t| Wrong number of arguments (Got 5) |\n\t| |\n\t| [Quit] [OK] |\n\t|___________________________________|\n\nIf I choose \"Quit\", the exit status is 0.\n\nBut how about this? \"meld --help | grep -e --output\" seems to detect\nsupport for the option reliably. With 2>&1 on the upstream of the\npipe, this even seems futureproof. ;-)\n\n mergetools/meld | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/mergetools/meld b/mergetools/meld\nindex eaa115cc..cb672a55 100644\n--- a/mergetools/meld\n+++ b/mergetools/meld\n@@ -23,7 +23,7 @@ check_meld_for_output_version () {\n \tmeld_path=\"$(git config mergetool.meld.path)\"\n \tmeld_path=\"${meld_path:-meld}\"\n \n-\tif \"$meld_path\" --output /dev/null --help >/dev/null 2>&1\n+\tif \"$meld_path\" --help 2>&1 | grep -e --output >/dev/null\n \tthen\n \t\tmeld_has_output_option=true\n \telse\n-- \n1.7.9\n"},{"id":"184411","messageId":"20120210222311.GB20703@unpythonic.net","threadId":"29582","inReplyTo":"20120210215755.GL19216@burratino","subject":"Re: [PATCH] mergetools/meld: Use --help output to detect --output support","fromName":"Jeff Epler","fromEmail":"jepler@unpythonic.net","sentAt":"2012-02-10T22:23:12Z","receivedAt":"2012-02-10T22:23:12Z","isPatch":true,"sender":{"key":"jepler@unpythonic.net","avatar":"https://avatars.githubusercontent.com/u/1517291?v=4"},"body":"I appreciate the interest you've all taken in my report, but I really\ndon't think there's any need to do anything about this \"problem\" besides\nlet people find this thread, in which they can learn to try upgrading\ntheir meld to one that's only 5 1/2 years old.\n\nThat said, another possibility is to test whether\n meld --commandline-option-that-cannot-possibly-exist --help\nexits with status 0; if it does, then exit-status based probing of\nmeld's capabilities won't work. In this case, assume --output is not\navailable.\n\nJeff\n\nOn Fri, Feb 10, 2012 at 03:57:55PM -0600, Jonathan Nieder wrote:\n> In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's \"meld\" support learned\n> to use the --output option when calling versions of meld that are\n> detected to support it (1.5.0 and newer, hopefully).\n> \n> Alas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as\n> supporting the option, so on systems with such meld, instead of\n> getting a nice merge helper, the operator gets a dialog box with the\n> text \"Wrong number of arguments (Got 5)\". (Version 1.1.5 is when meld\n> switched to using optparse. One consequence of that change was that\n> errors in usage are detected and signalled through the exit status\n> even when --help was passed.)\n> \n> Luckily there is a simpler check that is more reliable: the usage\n> string printed by \"meld --help\" reliably reflects whether --output is\n> supported in a given version. Use it.\n> \n> Reported-by: Jeff Epler \n> Signed-off-by: Jonathan Nieder \n> ---\n> Junio C Hamano wrote:\n> \n> > When an older meld fails when given --output for real (not with the dry\n> > run current code tries with --help), can we sanely detect that particular\n> > failure?\n> \n> Unfortunately it just pops up a GUI with a modal dialog box like this:\n> \t ___________________________________\n> \t| |\n> \t| Wrong number of arguments (Got 5) |\n> \t| |\n> \t| [Quit] [OK] |\n> \t|___________________________________|\n> \n> If I choose \"Quit\", the exit status is 0.\n> \n> But how about this? \"meld --help | grep -e --output\" seems to detect\n> support for the option reliably. With 2>&1 on the upstream of the\n> pipe, this even seems futureproof. ;-)\n> \n> mergetools/meld | 2 +-\n> 1 files changed, 1 insertions(+), 1 deletions(-)\n> \n> diff --git a/mergetools/meld b/mergetools/meld\n> index eaa115cc..cb672a55 100644\n> --- a/mergetools/meld\n> +++ b/mergetools/meld\n> @@ -23,7 +23,7 @@ check_meld_for_output_version () {\n> \tmeld_path=\"$(git config mergetool.meld.path)\"\n> \tmeld_path=\"${meld_path:-meld}\"\n> \n> -\tif \"$meld_path\" --output /dev/null --help >/dev/null 2>&1\n> +\tif \"$meld_path\" --help 2>&1 | grep -e --output >/dev/null\n> \tthen\n> \t\tmeld_has_output_option=true\n> \telse\n> -- \n> 1.7.9\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"184412","messageId":"20120210223008.GC20703@unpythonic.net","threadId":"29582","inReplyTo":"20120210215755.GL19216@burratino","subject":"Re: [PATCH] mergetools/meld: Use --help output to detect --output support","fromName":"Jeff Epler","fromEmail":"jepler@unpythonic.net","sentAt":"2012-02-10T22:30:09Z","receivedAt":"2012-02-10T22:30:09Z","isPatch":true,"sender":{"key":"jepler@unpythonic.net","avatar":"https://avatars.githubusercontent.com/u/1517291?v=4"},"body":"I can confirm that this iteration of the patch (meld --help | grep)\nworked for me on meld 1.1.1, meld 1.1.5, and meld 1.3.0. Note however\nthat none of these are versions of meld that do support the --output\nflag.\n\nTested-by: Jeff Epler \n\nJeff\n"}]}