comment

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 <file>..." 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.
+"""]]