From 218cb6ab56e18383c86f5f299a717b97df7bf155 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 7 Apr 2023 13:13:16 -0400 Subject: [PATCH] expand --- doc/todo/terminal_escapes_in_filenames.mdwn | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/doc/todo/terminal_escapes_in_filenames.mdwn b/doc/todo/terminal_escapes_in_filenames.mdwn index c12e74308d..8f6940c581 100644 --- a/doc/todo/terminal_escapes_in_filenames.mdwn +++ b/doc/todo/terminal_escapes_in_filenames.mdwn @@ -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