Steffen Nurpmeso wrote, on 18 Oct 2022:
>
> Austin Group Bug Tracker wrote in
> <2969d655ede7498ce22799a53d077...@austingroupbugs.net>:
> ...
> |https://austingroupbugs.net/view.php?id=249
> ...
> | https://austingroupbugs.net/view.php?id=249#c5995
> ...
> |If a \e or \cX escape sequence specifies a character that does not have an
> |encoding in the locale in effect when these backslash escape sequences are
>
> \e only yields escape U+1B?
> Since "this standard requires support for all of the control
> characters except NULL (matching what is done in the stty
> utility)" \e is always supported. It is in (US-)ASCII and thus
> ISO-8859-1 and thus in the lower 256 codepoints of Unicode.
> (It is also in that EBCDIC thing.)
"This standard requires support for all of the control characters except
NULL" just means that the shell is required to recognise $'\c[' as
specifying <ESC>, it doesn't mean that <ESC> has to have an encoding
in all locales. See XBD 6.2:
The POSIX locale [...]. Other locales shall contain the characters
in Table 6-1 (on page 105) and may contain any or all of the
control characters identified in Table 6-2 (on page 110)
<ESC> is in Table 6-2.
> And likewise in "the unsupported character might be replaced with
> multiple characters, shell-special or regular (e.g. if <ESC> is
> not supported $'\e' may be replaced by "???", "XXX" or "<ESC>")"
> \e seems a particularly bad example thus.
>
> (Also quotation-mark does not _need_ to be escaped, it can. It
> might be worthwhile to point this out? A few lines earlier.)
I can't see anything "a few lines earlier" that implies quotation-mark
needs to be escaped. Please give the exact wording change you would
like to see.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
