Re: \M-^C vs \203 vs \x83 as visual representations of bytes

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2024-02-25 12:26:35 -0500, Mark J. Reed:
> Wow; I had no idea Zsh printed out nonprintable characters that way. I
> concur that it would make sense to change, modulo backward compatibility
> considerations. Maybe a settable option?
[...]

Note that I'm not suggesting zsh stop accepting it on input, but
to change the output format.

On input, zsh supports \203 and \x83 more widely than \M-\C-C

Supported by print and $'...'

$ print '\x83\203\M-\C-C' | sed -n l
\203\203\203$
$ print -r $'\x83\203\M-\C-C' | sed -n l
\203\203\203$

But not:

$ echo '\x83\203\M-\C-C' | sed -n l
\203\\203\\M-\\C-C$
$ echo '\x83\0203\M-\C-C' | sed -n l
\203\203\\M-\\C-C$
$ printf '\x83\0203\M-\C-C\n' | sed -n l
\203\0203\\M-\\C-C$

So I wouldn't think the switch would break backward
compatibility. Switching to \203 or \x83 would actually improve
compatibility with other shells.

Ksh has \CC instead of \C-C (inside $'...') and it's \M-C seems to expand to
^[C (and \M-c doesn't seem to be recognised).

In ksh however, \xfff is the same as \ufff (while \xff is not
the same as \uff) and you need \x[ff]f or \x{ff}f to have a 0xff
byte followed by f. So the output would not be compatible with
ksh if switching to \xHH.

$ ksh -c 'printf "%q\n" "$@"' ksh $'\xff' $'\xfff'
$'\xff'
$'\x[ff]f'

See also
https://github.com/ksh93/ksh/commit/ac8991e5257978a6359c001b7fa227c334fd9e18

-- 
Stephane