Geoff Clare wrote in <Y0+mtrafUbGYk5Dr@localhost>: |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.
You are right, i see, U+001B is not in the portable character set, only an optional part of character sets. This is so far off daily live i would never have reflected that on my own. ISO 6429, ECMA-48, ECMA-35 from December 1971 includes it even. I downloaded a version, it is typewriter written. Thank you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
