git-annex/doc/todo/terminal_escapes_in_filenames.mdwn

    touch $(echo -e "\e[31mfoo\e[0m")
    git-annex add
    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, 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
either)

While terminals mostly protect against escape sequences doing very bad
things, there are security holes in terminals still being found.

Of course, such files in git repos can also be exploited by other commands
eg `echo *`. 

So this does not seem like a security hole in git-annex, but it would be
useful defense in depth against terminal security holes, and also good to
behave more like git.

--[[Joey]]

> Git.Filename.encode is implemented, and only needs to be used.
> Note that core.quotePath controls whether git quotes unicode characters
> (by default it does), so once this gets implemented, some users may want
> to set that config to false. --[[Joey]]