Process substitution can leak CTLESC (0x01) in output

[David Simmons]

[ Re-sending... it doesn't look like this went through the first time. ]

Bash uses 0x01 (CTLESC) and 0x7F (CTLNUL) bytes within command word 
strings that are passed around internally.  If either of these bytes 
appear in the parser input, they are escaped with an extra 0x01 
(CTLESC), but such escaping is reverted before final use.

When I use ANSI-C quoting to represent these bytes in a process 
substitution context, they appear to be CTLESC-encoded twice in their 
journey through bash.  For example, 7F becomes 01 7F which becomes 01 01 
01 7F, then decoded once as 01 7F before final use.  This leads to 
spurious 0x01 bytes.

Example:

----------%< snip %<----------
#!/bin/bash

# Expected output: 01
# Actual output:   01 01 (bad)
od -An -t x1 <(echo -n $'\x01')

# Expected output: 7f
# Actual output:   01 7f (bad)
od -An -t x1 <(echo -n $'\x7F')

# Expected output: 01
# Actual output:   01 (good)
echo -n $'\x01' | od -An -t x1

# Expected output: 7f
# Actual output:   7f (good)
echo -n $'\x7F' | od -An -t x1
----------%< snip %<----------

I've tested this on both 4.3.46(1)-release as provided by my OS vendor, 
and a 4.4.12(21)-release which I built from source.

David