From a127949e6519f3a86d0f9e32659cdc0c01d323bc Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 24 Apr 2023 16:05:35 -0400 Subject: [PATCH] comment --- ..._0fe421cd62c36804a78e4b424302e3d7._comment | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_3_0fe421cd62c36804a78e4b424302e3d7._comment diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_3_0fe421cd62c36804a78e4b424302e3d7._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_3_0fe421cd62c36804a78e4b424302e3d7._comment new file mode 100644 index 0000000000..439130d7c9 --- /dev/null +++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_3_0fe421cd62c36804a78e4b424302e3d7._comment @@ -0,0 +1,37 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2023-04-24T19:25:12Z" + content=""" +git escapes filenames like this extensively: + + joey@darkstar:~/tmp/xxx>git ls-files + "gl\\orious" + joey@darkstar:~/tmp/xxx>git status + Changes to be committed: + (use "git restore --staged ..." to unstage) + new file: "gl\\orious" + joey@darkstar:~/tmp/xxx>git grep hi + "gl\\orious":hi + +This message from `git add` escapes slightly differently, but it still escapes +some characters: + + joey@darkstar:~/tmp/xxx>git add $(echo -e "\e[31mfoo\e[0m") + fatal: pathspec '?[31mfoo?[0m' did not match any files + +Git only does this type of escaping when displaying a fatal error +(it's `vreportf` in the git source, used by things like `die`). +It's basically a last-ditch filtering of a string, which may contain a filename +or other untrusted data, to avoid displaying escape characters. git-annex does +contain such a last-ditch filtering too (safeOutput) but type safety let me avoid +needing to use it to handle this filename here. I don't think it's at all necessary +for git-annex to be bug-for-bug equivilant with git in its display of error +messages; but it is important that it escape somehow. Git's double-quoted escaping +is documented, and this other escaping is not. + +Since either behavior would be a behavior change from before when git-annex didn't +escape the filename in the error message with either method, it seems to me either +one would likely break your assumption. So I don't know why you're arguing for +one way over the other way. +"""]]