{"thread":{"id":"43033","subject":"[bug] git-check-ignore and file names with unicode chars in name - sys-out filename is corrupted","startedAt":"2016-08-09T05:47:24Z","lastAt":"2016-08-09T06:39:02Z","messageCount":2,"participants":["Paul Hammant","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"293455","messageId":"CA+298UiKf6heNPy-NZSfdx47jyS_aK+C8UX3vh6OB3_XE+pn=g@mail.gmail.com","threadId":"43033","inReplyTo":null,"subject":"[bug] git-check-ignore and file names with unicode chars in name - sys-out filename is corrupted","fromName":"Paul Hammant","fromEmail":"paul@hammant.org","sentAt":"2016-08-09T05:47:18Z","receivedAt":"2016-08-09T05:47:24Z","isPatch":false,"sender":{"key":"paul@hammant.org","avatar":null},"body":"Reproduction:\n\n  $ echo \"*.ignoreme\" >> .gitignore\n  # (and commit)\n  $ touch \"fooo-€.ignoreme\"\n  $ find . -print | grep fooo | xargs git check-ignore\n  \"./fooo-\\342\\202\\254.ignoreme\"\n\nYou could view that git-check-ignore isn't corrupting anything, it is\njust outputting another form for the file name (octal escaped), but it\ndoesn't need to change it at all, and its causing downstream problems\nin bash scripting.\n\nOf course this may get munged by gmail or a list manager. In the text\nabove, you should see unicode char \"euro sign\" to the right of a dash,\nand the left of .ignoreme\n\nGit version is 2.9.2\n\n-ph\n"},{"id":"293456","messageId":"20160809063854.GA17777@peff.net","threadId":"43033","inReplyTo":"CA+298UiKf6heNPy-NZSfdx47jyS_aK+C8UX3vh6OB3_XE+pn=g@mail.gmail.com","subject":"Re: [bug] git-check-ignore and file names with unicode chars in name - sys-out filename is corrupted","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-09T06:38:55Z","receivedAt":"2016-08-09T06:39:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 09, 2016 at 01:47:18AM -0400, Paul Hammant wrote:\n\n> Reproduction:\n> \n>   $ echo \"*.ignoreme\" >> .gitignore\n>   # (and commit)\n>   $ touch \"fooo-€.ignoreme\"\n>   $ find . -print | grep fooo | xargs git check-ignore\n>   \"./fooo-\\342\\202\\254.ignoreme\"\n> \n> You could view that git-check-ignore isn't corrupting anything, it is\n> just outputting another form for the file name (octal escaped), but it\n> doesn't need to change it at all, and its causing downstream problems\n> in bash scripting.\n\nIt's not corrupted; like all git commands, check-ignore by default\nprints paths with a reversible quoting mechanism, so that odd filenames\nare not syntactically ambiguous (e.g., consider a filename with a\nnewline in it), and so that you don't get binary spew on your terminal.\n\nFor robust scripting, you can either:\n\n  - unquote the filenames in the receiving script (detect the presence\n    of quoting by the double-quote in the first character, and then\n    normal C-style dequoting).\n\nor\n\n  - use \"-z\" to get NUL-delimited filenames with no quoting. Your\n    example above has problems in the find, grep, and xargs\n    commands, too. A more careful version is:\n\n      find . -print0 | grep -z fooo | git check-ignore --stdin -z\n\nFor human readability, you can do:\n\n  git config core.quotepath false\n\nto avoid quoting binary characters (here and in other tools like \"git\ndiff\"), which is convenient if you use UTF8 filenames. It also will\n\"unbreak\" your scripts in the sense that it will avoid quoting in more\nsituations. The scripts would still choke on more weird filenames\n(e.g., ones with embedded tabs or newlines), but in practice you'd\nprobably never notice.\n\n-Peff\n"}]}