)]}'
{
  "commit": "ef91d3d6a4c39421fd3a391e02cd82f9f3aee4a8",
  "tree": "9d7e3577d31c1a291835b1ab4752dc7d507f44f7",
  "parents": [
    "339b9c0781cca7afb0964c6a655cda8ad9cf9fc2"
  ],
  "author": {
    "name": "Herbert Xu",
    "email": "herbert@gondor.apana.org.au",
    "time": "Mon Sep 29 22:52:41 2014 +0800"
  },
  "committer": {
    "name": "Herbert Xu",
    "email": "herbert@gondor.apana.org.au",
    "time": "Mon Sep 29 22:52:41 2014 +0800"
  },
  "message": "[PARSER] Handle backslash newlines properly after dollar sign\n\nOn Tue, Aug 26, 2014 at 12:34:42PM +0000, Eric Blake wrote:\n\u003e On 08/26/2014 06:15 AM, Oleg Bulatov wrote:\n\u003e \u003e Hi!\n\u003e \u003e \n\u003e \u003e While playing with sh generators I found that dash and bash have different\n\u003e \u003e interpretations for \u003cslash\u003e\u003cnewline\u003e sequence.\n\u003e \u003e \n\u003e \u003e $ dash -c \u0027EDIT\u003dxxx; echo $EDIT\\\n\u003e \u003e\u003e OR\u0027\n\u003e \u003e xxxOR\n\u003e \n\u003e Buggy.\n\u003e \n\u003e \u003e $ bash -c \u0027EDIT\u003dxxx; echo $EDIT\\\n\u003e \u003e OR\u0027\n\u003e \u003e /usr/bin/vim\n\u003e \n\u003e Correct behavior.\n\u003e \n\u003e \u003e \n\u003e \u003e $ dash -c \u0027echo \"$\\\n\u003e \u003e (pwd)\"\u0027\n\u003e \u003e $(pwd)\n\u003e \u003e \n\u003e \u003e Is it undefined behaviour in POSIX?\n\u003e \n\u003e No, it\u0027s well-defined, and dash is buggy.  POSIX says:\n\u003e \n\u003e http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03\n\u003e \n\u003e \"the shell shall break its input into tokens by applying the first\n\u003e applicable rule below to the next character in its input\"\n\u003e \n\u003e Rule 4 covers backslash handling, while rule 5 covers locating the end\n\u003e of a word to be subject to $ expansion.  Therefore, rule 4 should happen\n\u003e first.  Rule 4 defers to the section on quoting, with the caveat that\n\u003e \u003cnewline\u003e joining is the only substitution that happens immediately as\n\u003e part of the parsing:\n\u003e \n\u003e http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02\n\u003e \n\u003e \"If a \u003cnewline\u003e follows the \u003cbackslash\u003e, the shell shall interpret this\n\u003e as line continuation. The \u003cbackslash\u003e and \u003cnewline\u003e shall be removed\n\u003e before splitting the input into tokens. Since the escaped \u003cnewline\u003e is\n\u003e removed entirely from the input and is not replaced by any white space,\n\u003e it cannot serve as a token separator.\"\n\u003e \n\u003e So the fact that dash is treating the elided backslash-newline as a\n\u003e token separator, and parsing your input as if ${EDIT}OR instead of\n\u003e ${EDITOR} is a bug in dash.\n\nI agree.  This patch should resolve this problem and similar ones\naffecting blackslash newlines after we encounter a dollar sign.\n\nSigned-off-by: Herbert Xu \u003cherbert@gondor.apana.org.au\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0fbc514680c24970a810dc86a6987088df9e23d6",
      "old_mode": 33188,
      "old_path": "ChangeLog",
      "new_id": "398bd15bbb517fb04043e812255f3a46a4cd959c",
      "new_mode": 33188,
      "new_path": "ChangeLog"
    },
    {
      "type": "modify",
      "old_id": "c4eaae2b93d55023dadf1c2d48333e379eaf993c",
      "old_mode": 33188,
      "old_path": "src/parser.c",
      "new_id": "2b07437e99751014ad23798974fcecab3faa57e3",
      "new_mode": 33188,
      "new_path": "src/parser.c"
    }
  ]
}