{"thread":{"id":"57301","subject":"[RFC] shell: local x=$1 may need to quote the RHS","startedAt":"2022-01-24T20:20:41Z","lastAt":"2022-01-27T00:17:07Z","messageCount":9,"participants":["Junio C Hamano","Konstantin Khomoutov","Taylor Blau","SZEDER Gábor"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"446806","messageId":"xmqqsftc3nd6.fsf@gitster.g","threadId":"57301","inReplyTo":null,"subject":"[RFC] shell: local x=$1 may need to quote the RHS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-01-24T20:11:33Z","receivedAt":"2022-01-24T20:20:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Even though this message ends with a patch that could be applied to\nyour tree, it is not for application at all.  It is to demonstrate a\npotential problem in the code in our tree. \n\nWhile I was playing with the \"Linux development environment (beta)\"\non one of my Chromebooks, I say its default /bin/sh (which is Dash\n0.5.10) mishandled this construct:\n\n\tfunc () {\n\t\tlocal x=$1\n\t\tclobber x and nothing else and feel safe\n\t\tmessage=\"I expect this to be visible by the caller\"\n\t}\n\n\tfunc \"a message\"\n\tuse \"$message\"\n\nIt assigned 'a' to $x in the function, DECLARED the varilable\n$message as local to the function, hence the caller after func\nreturned did not see what I intended to see in $message.\n\nThe breakage is subtle; unless you have a character in $1 that would\nnot make a valid variable name, you won't get any error message yet\nthe program would behave in an unexpected way.\n\nIn other words, all of these hits are suspect and may misbehave with\nsuch a shell.\n\n    $ git grep -e '^[\t ]*local.* [a-z0-9_]*=\\$' t\n    t/lib-parallel-checkout.sh:\tlocal expected_workers=$1 &&\n    t/t0000-basic.sh:\tlocal x=$1\n    t/t4011-diff-symlink.sh:\tlocal oid=$(printf \"%s\" \"$1\" | git hash-object --stdin) &&\n    t/t4011-diff-symlink.sh:\tlocal oid=$(git hash-object \"$1\") &&\n    t/t4210-log-i18n.sh:\tlocal engine=$1\n    t/t4210-log-i18n.sh:\tlocal pattern=$1\n    t/test-lib-functions.sh:\tlocal basename=${1#??}\n    t/test-lib-functions.sh:\tlocal var=$1 port\n    t/test-lib-functions.sh:\tlocal expr=$(printf '\"%s\",' \"$@\")\n    t/test-lib-functions.sh:\tlocal expr=$(printf '\"%s\".*' \"$@\")\n\nOutside t/, I didn't find anything that may be run with dash and\ncan be fed problematic input, so as far as I can tell, it is a\nproblem that only affects the current set of tests.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n t/t0000-basic.sh | 13 +++++++++++++\n 1 file changed, 13 insertions(+)\n\ndiff --git c/t/t0000-basic.sh w/t/t0000-basic.sh\nindex b007f0efef..915eb2384f 100755\n--- c/t/t0000-basic.sh\n+++ w/t/t0000-basic.sh\n@@ -45,6 +45,19 @@ test_expect_success 'verify that the running shell supports \"local\"' '\n \ttest_cmp expected2 actual2\n '\n \n+try_local_unquoted () {\n+\tlocal x=$1\n+\ty=\"newvalue\"\n+}\n+\n+test_expect_success 'verify that \"local x=$1\" do not quoting' '\n+\ty=oldvalue &&\n+\techo \"newvalue\" >expect &&\n+\ttry_local_unquoted \"x y\" &&\n+\techo \"$y\" >actual &&\n+\ttest_cmp expect actual\n+'\n+\n ################################################################\n # git init has been done in an empty repository.\n # make sure it is empty.\n"},{"id":"446834","messageId":"20220125092419.cgtfw32nk2niazfk@carbon","threadId":"57301","inReplyTo":"xmqqsftc3nd6.fsf@gitster.g","subject":"Re: [RFC] shell: local x=$1 may need to quote the RHS","fromName":"Konstantin Khomoutov","fromEmail":"kostix@bswap.ru","sentAt":"2022-01-25T09:24:19Z","receivedAt":"2022-01-25T09:28:20Z","isPatch":false,"sender":{"key":"kostix@bswap.ru","avatar":null},"body":"On Mon, Jan 24, 2022 at 12:11:33PM -0800, Junio C Hamano wrote:\n\n> Even though this message ends with a patch that could be applied to\n> your tree, it is not for application at all.  It is to demonstrate a\n> potential problem in the code in our tree. \n> \n> While I was playing with the \"Linux development environment (beta)\"\n> on one of my Chromebooks, I say its default /bin/sh (which is Dash\n> 0.5.10) mishandled this construct:\n> \n> \tfunc () {\n> \t\tlocal x=$1\n> \t\tclobber x and nothing else and feel safe\n> \t\tmessage=\"I expect this to be visible by the caller\"\n> \t}\n> \n> \tfunc \"a message\"\n> \tuse \"$message\"\n> \n> It assigned 'a' to $x in the function, DECLARED the varilable\n> $message as local to the function, hence the caller after func\n> returned did not see what I intended to see in $message.\n> \n> The breakage is subtle; unless you have a character in $1 that would\n> not make a valid variable name, you won't get any error message yet\n> the program would behave in an unexpected way.\n\nSorry, I might have not followed the entire thread, but assignment in\n`local` is a bashism, and dash can only handle the declaration part with\n`local`, not assignment; hence the safe code should read\n\n  local x\n  x=\"$1\"\n\nTo cite the dash manual page:\n\n| Variables may be declared to be local to a function by using a local\n| command.  This should appear as the first statement of a function, and the\n| syntax is\n| \n|    local [variable | -] ...\n| \n| Local is implemented as a builtin command.\n| \n| When a variable is made local, it inherits the initial value and exported\n| and readonly flags from the variable with the same name in the surrounding\n| scope, if there is one.  Otherwise, the vari‐ able is initially unset.  The\n| shell uses dynamic scoping, so that if you make the variable x lo‐ cal to\n| function f, which then calls function g, references to the variable x made\n| inside g will refer to the variable x declared inside f, not to the global\n| variable named x.\n| \n| The only special parameter that can be made local is “-”.  Making “-” local\n| any shell options that are changed via the set command inside the function\n| to be restored to their original values\n| when the function returns.\n\n"},{"id":"446865","messageId":"xmqqa6fjzlm0.fsf@gitster.g","threadId":"57301","inReplyTo":"20220125092419.cgtfw32nk2niazfk@carbon","subject":"Re: [RFC] shell: local x=$1 may need to quote the RHS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-01-25T19:00:39Z","receivedAt":"2022-01-25T19:01:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Konstantin Khomoutov <kostix@bswap.ru> writes:\n\n> Sorry, I might have not followed the entire thread, but assignment in\n> `local` is a bashism, and dash can only handle the declaration part with\n> `local`, not assignment; hence the safe code should read\n>\n>   local x\n>   x=\"$1\"\n\nInteresting.  As \"local\" is not in POSIX but we still use it for\nconvenience, we must limit our use to a reasonable subset of\nfeatures common to the shells we care about.  Knowing what each\nshell can and cannot do safely is essential to us.\n\nThe patch posted seemed to run fine with a more recent dash than\nwhat I had trouble with (0.5.10 would work fine with \"$1\" quoted,\n0.5.11 would work fine without $1, just like the RHS of a regular\nassignment).  In addition, there are many existing tests that\nalready use \"local var=initial-value\" (the message you are\nresponding to has an output from \"grep\") and we haven't got problem\nreports from dash users about them.\n\nThe manual page for recent dash may need an update.\nCan you perhaps file a bug on their documentation?\n\nThanks.\n"},{"id":"446869","messageId":"YfBbRca0Rjl59MM0@nand.local","threadId":"57301","inReplyTo":"xmqqa6fjzlm0.fsf@gitster.g","subject":"Re: [RFC] shell: local x=$1 may need to quote the RHS","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-01-25T20:19:17Z","receivedAt":"2022-01-25T20:19:22Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Jan 25, 2022 at 11:00:39AM -0800, Junio C Hamano wrote:\n> Konstantin Khomoutov <kostix@bswap.ru> writes:\n>\n> > Sorry, I might have not followed the entire thread, but assignment in\n> > `local` is a bashism, and dash can only handle the declaration part with\n> > `local`, not assignment; hence the safe code should read\n> >\n> >   local x\n> >   x=\"$1\"\n>\n> Interesting.  As \"local\" is not in POSIX but we still use it for\n> convenience, we must limit our use to a reasonable subset of\n> features common to the shells we care about.  Knowing what each\n> shell can and cannot do safely is essential to us.\n>\n> The patch posted seemed to run fine with a more recent dash than\n> what I had trouble with (0.5.10 would work fine with \"$1\" quoted,\n> 0.5.11 would work fine without $1, just like the RHS of a regular\n> assignment).  In addition, there are many existing tests that\n> already use \"local var=initial-value\" (the message you are\n> responding to has an output from \"grep\") and we haven't got problem\n> reports from dash users about them.\n\nYeah; bisecting dash with your example script pointed me at cbb71a8\n(eval: Add assignment built-in support again, 2018-05-19), which indeed\nappears in v0.5.11 (and all subsequent versions).\n\ncbb71a8 points at release 0.3.8-15, which predates Git (and a tag\npointing at it was never created, since it's behind the big \"initial\nimport\" commit at the beginning of dash.git's history). But skimming\nChangeLog.O, we see:\n\n    * Removed assignment builtins since it is at best undefined by the\n      SuS and also can't be implemented consistently.\n\nSo this probably didn't work at all between that 0.3.8-15 up until v0.5.11.\n\n> The manual page for recent dash may need an update.\n> Can you perhaps file a bug on their documentation?\n\nYes, I agree that dash.1 is out-of-date after cbb71a8. Konstantin:\nplease feel free to use any of this if it's helpful to you in creating a\nbug report for the dash folks.\n\nThanks,\nTaylor\n"},{"id":"446913","messageId":"xmqqo83zt54a.fsf@gitster.g","threadId":"57301","inReplyTo":"YfBbRca0Rjl59MM0@nand.local","subject":"Re: [RFC] shell: local x=$1 may need to quote the RHS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-01-26T05:53:25Z","receivedAt":"2022-01-26T05:53:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau <me@ttaylorr.com> writes:\n\n> Yeah; bisecting dash with your example script pointed me at cbb71a8\n> (eval: Add assignment built-in support again, 2018-05-19), which indeed\n> appears in v0.5.11 (and all subsequent versions).\n>\n> cbb71a8 points at release 0.3.8-15, which predates Git (and a tag\n> pointing at it was never created, since it's behind the big \"initial\n> import\" commit at the beginning of dash.git's history). But skimming\n> ChangeLog.O, we see:\n>\n>     * Removed assignment builtins since it is at best undefined by the\n>       SuS and also can't be implemented consistently.\n>\n> So this probably didn't work at all between that 0.3.8-15 up until v0.5.11.\n>\n>> The manual page for recent dash may need an update.\n>> Can you perhaps file a bug on their documentation?\n>\n> Yes, I agree that dash.1 is out-of-date after cbb71a8. Konstantin:\n> please feel free to use any of this if it's helpful to you in creating a\n> bug report for the dash folks.\n\nI doubt that we can write off dash v0.5.10 as too old to matter, as\nthe tagger date seems to be mid 2020 at \n\nhttps://kernel.googlesource.com/pub/scm/utils/dash/dash/+/refs/tags/v0.5.11\n\n\nSo here is a bit wider \"grep\" output, looking for\n\n$ git grep '^[ \t]*local[\t ].*=' \\*.sh\n\nto reject _any_ assignment on the same line as \"local\", but I\nmanually excluded the ones that are not meant to be run with dash.\nI obviously excluded the one in t0000 (try_local_xy) that is a\nweather-balloon for this exact issue.\n\nAccording to this thread, these would not work correctly on dash\nolder than 0.5.11 and needs fixing by splitting declaration of\nvariables as locals and assignment of their initial values.\n\n\ncontrib/subtree/git-subtree.sh:\tlocal indent=$(($indent + 1))\ncontrib/subtree/git-subtree.sh:\tlocal indent=$(($indent + 1))\ncontrib/subtree/git-subtree.sh:\tlocal indent=$(($indent + 1))\ncontrib/subtree/git-subtree.sh:\tlocal grep_format=\"^git-subtree-dir: $dir/*\\$\"\ncontrib/subtree/git-subtree.sh:\tlocal rev=\"$1\"\ncontrib/subtree/git-subtree.sh:\tlocal parents=\"$2\"\ncontrib/subtree/git-subtree.sh:\tlocal indent=$(($indent + 1))\nt/lib-parallel-checkout.sh:\tlocal expected_workers=$1 &&\nt/lib-parallel-checkout.sh:\tlocal trace_file=trace-test-checkout-workers &&\nt/lib-parallel-checkout.sh:\tlocal workers=\"$(grep \"child_start\\[..*\\] git checkout--worker\" \"$trace_file\" | wc -l)\" &&\nt/t0021-conversion.sh:\t\tlocal expect_progress=N &&\nt/t0021-conversion.sh:\t\tlocal expect_progress=\nt/t3435-rebase-gpg-sign.sh:\tlocal must_fail= will=will fake_editor=\nt/t3514-cherry-pick-revert-gpg.sh:\tlocal must_fail= will=will fake_editor=\nt/t4011-diff-symlink.sh:\tlocal oid=$(printf \"%s\" \"$1\" | git hash-object --stdin) &&\nt/t4011-diff-symlink.sh:\tlocal oid=$(git hash-object \"$1\") &&\nt/t4210-log-i18n.sh:\tlocal engine=$1\nt/t4210-log-i18n.sh:\tlocal pattern=$1\nt/t6006-rev-list-format.sh:\tlocal args=\nt/t6006-rev-list-format.sh:\tlocal args=\nt/t9902-completion.sh:\tlocal IFS=$'\\n'\nt/t9902-completion.sh:\tlocal cur=\"$1\" &&\nt/t9902-completion.sh:\tlocal cur=\"$1\" &&\nt/t9902-completion.sh:\tlocal cur=\"$1\" expected=\"$2\"\nt/test-lib-functions.sh:\tlocal op='=' wrong_result=different\nt/test-lib-functions.sh:\tlocal test_cmp_a= test_cmp_b=\nt/test-lib-functions.sh:\tlocal stdin_for_diff=\nt/test-lib-functions.sh:\tlocal algo=\"${test_hash_algo}\" &&\nt/test-lib-functions.sh:\tlocal var=\"test_oid_${algo}_$1\" &&\nt/test-lib-functions.sh:\tlocal basename=${1#??}\nt/test-lib-functions.sh:\tlocal var=$1 port\nt/test-lib-functions.sh:\tlocal negate=\nt/test-lib-functions.sh:\tlocal expr=$(printf '\"%s\",' \"$@\")\nt/test-lib-functions.sh:\tlocal negate=\nt/test-lib-functions.sh:\tlocal expr=$(printf '\"%s\".*' \"$@\")\nt/test-lib-functions.sh:\tlocal expect_exit=0\nt/test-lib.sh:\tlocal opt=\"$1\"\nt/test-lib.sh:\tlocal bail_out=\"Bail out! \"\nt/test-lib.sh:\tlocal message=\"$1\"\n"},{"id":"446936","messageId":"20220126113939.cl5pbcous4gmdjri@carbon","threadId":"57301","inReplyTo":"xmqqo83zt54a.fsf@gitster.g","subject":"Re: [RFC] shell: local x=$1 may need to quote the RHS","fromName":"Konstantin Khomoutov","fromEmail":"kostix@bswap.ru","sentAt":"2022-01-26T11:39:39Z","receivedAt":"2022-01-26T11:39:45Z","isPatch":false,"sender":{"key":"kostix@bswap.ru","avatar":null},"body":"On Tue, Jan 25, 2022 at 09:53:25PM -0800, Junio C Hamano wrote:\n\n> Taylor Blau <me@ttaylorr.com> writes:\n> \n>> Yeah; bisecting dash with your example script pointed me at cbb71a8\n>> (eval: Add assignment built-in support again, 2018-05-19), which indeed\n>> appears in v0.5.11 (and all subsequent versions).\n>>\n>> cbb71a8 points at release 0.3.8-15, which predates Git (and a tag\n>> pointing at it was never created, since it's behind the big \"initial\n>> import\" commit at the beginning of dash.git's history). But skimming\n>> ChangeLog.O, we see:\n>>\n>>     * Removed assignment builtins since it is at best undefined by the\n>>       SuS and also can't be implemented consistently.\n>>\n>> So this probably didn't work at all between that 0.3.8-15 up until v0.5.11.\n[...]\n> So here is a bit wider \"grep\" output, looking for\n> \n> $ git grep '^[ \t]*local[\t ].*=' \\*.sh\n> \n> to reject _any_ assignment on the same line as \"local\", but I\n> manually excluded the ones that are not meant to be run with dash.\n> I obviously excluded the one in t0000 (try_local_xy) that is a\n> weather-balloon for this exact issue.\n> \n> According to this thread, these would not work correctly on dash\n> older than 0.5.11 and needs fixing by splitting declaration of\n> variables as locals and assignment of their initial values.\n\nBy the way, back then when Debian and Ubuntu were switching running their\nsystem scripts from bash to dash (which bought definite speedups), many\nscripts had to get rid of bashisms, and this page [1] summarizes quite many\ndifferences between these shells including handing of `local`.\nTo cite it:\n\n| Dash (old versions maybe?) and (at least) bash do not handle local the same:\n|\n| -    local a=5 b=6;\n| +    local a=5;\n| +    local b=6;\n|\n| The first line in /bin/bash makes a and b local variables. And in /bin/dash\n| this line makes b a global variable! \n\nNot sure it lists a possible problems our test harness also has but wanted to\ngive a heads-up anyway just in case.\n\n 1. https://wiki.ubuntu.com/DashAsBinSh\n\n"},{"id":"447002","messageId":"20220126214824.GA2581@szeder.dev","threadId":"57301","inReplyTo":"xmqqo83zt54a.fsf@gitster.g","subject":"Re: [RFC] shell: local x=$1 may need to quote the RHS","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2022-01-26T21:48:24Z","receivedAt":"2022-01-26T21:48:33Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Jan 25, 2022 at 09:53:25PM -0800, Junio C Hamano wrote:\n> Taylor Blau <me@ttaylorr.com> writes:\n> \n> > Yeah; bisecting dash with your example script pointed me at cbb71a8\n> > (eval: Add assignment built-in support again, 2018-05-19), which indeed\n> > appears in v0.5.11 (and all subsequent versions).\n> >\n> > cbb71a8 points at release 0.3.8-15, which predates Git (and a tag\n> > pointing at it was never created, since it's behind the big \"initial\n> > import\" commit at the beginning of dash.git's history). But skimming\n> > ChangeLog.O, we see:\n> >\n> >     * Removed assignment builtins since it is at best undefined by the\n> >       SuS and also can't be implemented consistently.\n> >\n> > So this probably didn't work at all between that 0.3.8-15 up until v0.5.11.\n> >\n> >> The manual page for recent dash may need an update.\n> >> Can you perhaps file a bug on their documentation?\n> >\n> > Yes, I agree that dash.1 is out-of-date after cbb71a8. Konstantin:\n> > please feel free to use any of this if it's helpful to you in creating a\n> > bug report for the dash folks.\n> \n> I doubt that we can write off dash v0.5.10 as too old to matter, as\n> the tagger date seems to be mid 2020 at \n> \n> https://kernel.googlesource.com/pub/scm/utils/dash/dash/+/refs/tags/v0.5.11\n\nI agree, and v0.5.10 is widely used, as it is the default shell in\nUbuntu 20.04 LTS.\n\n> So here is a bit wider \"grep\" output, looking for\n> \n> $ git grep '^[ \t]*local[\t ].*=' \\*.sh\n> \n> to reject _any_ assignment on the same line as \"local\", but I\n> manually excluded the ones that are not meant to be run with dash.\n> I obviously excluded the one in t0000 (try_local_xy) that is a\n> weather-balloon for this exact issue.\n> \n> According to this thread, these would not work correctly on dash\n> older than 0.5.11 and needs fixing by splitting declaration of\n> variables as locals and assignment of their initial values.\n\nI don't think that's necessary.  Whatever that (apparently horribly\noutdated) documentation might state, I think what really matters is\nwhat dash actually does.\n\nThe patch below puts a bit more strain on our `local` weatherballoon\ntest:\n\n  - It checks assignments from a parameter expansion and command\n    substitution as well, not only simple string assignments.\n\n  - The expanded values contain spaces and are quoted (to avoid the\n    field splitting issue that started this thread [1]).\n\n  - Creates a local variable with a name that doesn't hide an already\n    existing variable in the global scope, to see whether it becomes\n    global.\n\nIt succeeds with all tagged dash versions, the oldest being v0.5.2\ntagged on 2005-01-31.  I think that's more than old enough to say that\nit's not necessary to put local variable declaration and assignment on\ndifferent lines, and we can declare multiple local variables on one\nline.\n\nNote that NetBSD 8.1's /bin/sh need quotes on the RHS in similar\nassignments as well.\n\n[1] We've already run into this issue in ebee5580ca\n    (parallel-checkout: avoid dash local bug in tests, 2021-06-06),\n    but apparently didn't think through what else might be affected by\n    that bug.\n\n\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex 03fead95e7..196106fdf5 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -22,8 +22,8 @@ modification *should* take notice and update the test vectors here.\n . \"$TEST_DIRECTORY\"/lib-subtest.sh\n \n try_local_xy () {\n-\tlocal x=\"local\" y=\"alsolocal\" &&\n-\techo \"$x $y\"\n+\tlocal x=\"local\" y=\"${no_such_var-also local}\" z=\"$(echo \"third local\")\" &&\n+\techo \"$x $y $z\"\n }\n \n # Check whether the shell supports the \"local\" keyword. \"local\" is not\n@@ -37,11 +37,11 @@ try_local_xy () {\n test_expect_success 'verify that the running shell supports \"local\"' '\n \tx=\"notlocal\" &&\n \ty=\"alsonotlocal\" &&\n-\techo \"local alsolocal\" >expected1 &&\n+\techo \"local also local third local\" >expected1 &&\n \ttry_local_xy >actual1 &&\n \ttest_cmp expected1 actual1 &&\n-\techo \"notlocal alsonotlocal\" >expected2 &&\n-\techo \"$x $y\" >actual2 &&\n+\techo \"notlocal alsonotlocal z_unset\" >expected2 &&\n+\techo \"$x $y ${z-z_unset}\" >actual2 &&\n \ttest_cmp expected2 actual2\n '\n \n"},{"id":"447004","messageId":"YfHCoR2VSad95Cpu@nand.local","threadId":"57301","inReplyTo":"xmqqo83zt54a.fsf@gitster.g","subject":"Re: [RFC] shell: local x=$1 may need to quote the RHS","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-01-26T21:52:33Z","receivedAt":"2022-01-26T21:52:36Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Jan 25, 2022 at 09:53:25PM -0800, Junio C Hamano wrote:\n> Taylor Blau <me@ttaylorr.com> writes:\n> >\n> >> The manual page for recent dash may need an update.\n> >> Can you perhaps file a bug on their documentation?\n> >\n> > Yes, I agree that dash.1 is out-of-date after cbb71a8. Konstantin:\n> > please feel free to use any of this if it's helpful to you in creating a\n> > bug report for the dash folks.\n>\n> I doubt that we can write off dash v0.5.10 as too old to matter, as\n> the tagger date seems to be mid 2020 at\n>\n> https://kernel.googlesource.com/pub/scm/utils/dash/dash/+/refs/tags/v0.5.11\n\nThat isn't quite what I was implying. What I meant to say was that the\ndash _manual page_ is out-of-date w.r.t. the dash patch I linked, not\nthat that version is something we could ignore.\n\nThanks,\nTaylor\n"},{"id":"447021","messageId":"xmqqlez2nibl.fsf@gitster.g","threadId":"57301","inReplyTo":"YfHCoR2VSad95Cpu@nand.local","subject":"Re: [RFC] shell: local x=$1 may need to quote the RHS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-01-27T00:17:02Z","receivedAt":"2022-01-27T00:17:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau <me@ttaylorr.com> writes:\n\n> On Tue, Jan 25, 2022 at 09:53:25PM -0800, Junio C Hamano wrote:\n>> Taylor Blau <me@ttaylorr.com> writes:\n>> >\n>> >> The manual page for recent dash may need an update.\n>> >> Can you perhaps file a bug on their documentation?\n>> >\n>> > Yes, I agree that dash.1 is out-of-date after cbb71a8. Konstantin:\n>> > please feel free to use any of this if it's helpful to you in creating a\n>> > bug report for the dash folks.\n>>\n>> I doubt that we can write off dash v0.5.10 as too old to matter, as\n>> the tagger date seems to be mid 2020 at\n>>\n>> https://kernel.googlesource.com/pub/scm/utils/dash/dash/+/refs/tags/v0.5.11\n>\n> That isn't quite what I was implying. What I meant to say was that the\n> dash _manual page_ is out-of-date w.r.t. the dash patch I linked, not\n> that that version is something we could ignore.\n\nOh, I didn't mean it that way.  I was continuing from your findings\nthat certain features of \"local\" may not have been available in\n0.5.10; hence the hits from grep that showed any assignment might be\nproblematic with that version and we may need to downgrade our\nscripts.\n\nBut as Szeder writes in a response later in the thread, assignment\non \"local\" may have been avaiable in versions before 0.5.11 in a\nlimited form (namely, it is split at $IFS unlike normal assignments,\nwhich was the starting point of this thread), which reduces the\nscope of downgrading necessary by a large margin ;-)\n\n"}]}