expand
authorJoey Hess <joeyh@joeyh.name>
Fri, 7 Apr 2023 17:13:16 +0000 (13:13 -0400)
committerJoey Hess <joeyh@joeyh.name>
Fri, 7 Apr 2023 17:13:16 +0000 (13:13 -0400)
doc/todo/terminal_escapes_in_filenames.mdwn

index c12e74308d05f637630c44f8bbff5e58f1a68ce8..8f6940c581f7cbcf10a6306aa2bd3f8e0f781248 100644 (file)
@@ -1,12 +1,24 @@
     touch $(echo -e "\e[31mfoo\e[0m")
     git-annex add
-    git-annex find
+    git-annex whereis
 
 That displays "foo" in red twice. Compare with behavior of git commands that
 display that filename, which display it escaped.
 
-git-annex should probably do the same (except in json output which is
-already escaped).
+git-annex should probably do the same, when displaying filenames that it's
+working on or in messages.
+
+`git-annex find` is an interesting case because it's expected to be
+pipeable, and so should have raw filenames. Note that `find` actually
+escapes such filenames when outputting to a terminal, but not a pipe.
+
+It's possible that keys can also contain an escape sequence, eg in the
+extension of a SHA-E key. So commands like `git-annex lookupkey` 
+and `git-annex find` that output keys might need to handle
+that, when outputting to a terminal?
+
+`git-annex metadata` could also contain an escape sequence. So could 
+`git-annex config --get`.
 
 git porcelain also accepts the escaped form of files as input, necessary for
 round-tripping though. git-annex currently does not. (git plumbing doesn't