:A modifier reacts badly to pattern meta-characters

[okdana]

(workers/42259)

Hey there. I ran into the following problem today:

% print -r ${${:-a-b}:a}
/Users/dana/a-b
% print -r ${${:-a-b}:A}
/Users/dana/a?b

The ? in the second one is 0x9b (Dash).

Both chabspath() (:a) and chrealpath() (:A) receive the input as $'a\x9bb'. :a
doesn't care, because all it's doing is manipulating . and / in the string.
It is a concern for :A, though, because it has to pass the string to realpath(),
and then it has to metafy() the result. There are two related issues, then:

1. chrealpath() can't resolve paths passed into it this way if they contain
   pattern meta characters (any of them, not just -). It calls unmetafy(), but
   that doesn't help here.

2. chrealpath() metafies the result at the end, converting (e.g.) $'.../a\x9bb'
   into $'.../a\x83\xbbb', which breaks the expansion even in cases where it'd
   be accidentally correct (like the one above).

(Quoting/escaping the expansion works around these. So does assigning 'a-b' to a
variable first, as long as you don't do something like ${${~str}:A}.)

Simply having chrealpath() call untokenize() after unmetafy() fixes the above
test case, but then there's a new problem: ${:-a-b} and ${:-$'a\x9bb'} are
indistinguishable to the function and thus give the same result. This would
break resolution of multi-byte file names, as in ${${:-ツ}:A} (ツ = $'\u30c4' =
$'\xe3\x83\x84').

Just to clarify, both :a and :P seem unaffected, though in :a's case it seems like it only gets it right by accident. I didn't check the actual code for :P.