expand
This commit is contained in:
parent
e6a4782b0c
commit
218cb6ab56
1 changed files with 15 additions and 3 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue