Re: ASCII control codes in sequences of multibyte character sets

"Doug Ewell" <doug_at_ewellic.org> wrote:
 |The restrictions against <period> and <slash> would seem to exist to
 |prevent file and path names with multi-byte characters from being
 |corrupted. This isn't an issue for <newline> and <carriage-return>; my
 |understanding is that those can occur freely within POSIX file and path
 |names. So excluding them would be a new requirement, not merely a
 |"clarification."

This is nice – yes, they are completely free, and may be placed
loosely in between and after all ^Z bytes that may possibly occur.
Thus, if <newline> were part of a multibyte character, many Unix
tools would produce line breaks at faulty positions (producing
garbled or at least ugly output in pagers).
(But unfortunately i can only choose from "comment",
"clarification" and "enhancement request"..)

 |--
 |Doug Ewell | Thornton, CO, USA
 |http://ewellic.org | @DougEwell ­

--steffen

attached mail follows:

SteffenDaodeNurpmeso wrote:

> Reading your messages it seems safe to request a clarification of
> a POSIX wording (Base Definitions, 6.2 Character Encoding; [1]),
> from
>
> Likewise, the byte values used to encode <period> and <slash>
> shall not occur as part of any other character in any locale.
>
> to
>
> Likewise, the byte values used to encode <period>, <slash>,
> <newline> and <carriage-return> shall not occur as part of any
> other character in any locale.
>
> [1]
> <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html#tag_06>

The restrictions against <period> and <slash> would seem to exist to
prevent file and path names with multi-byte characters from being
corrupted. This isn't an issue for <newline> and <carriage-return>; my
understanding is that those can occur freely within POSIX file and path
names. So excluding them would be a new requirement, not merely a
"clarification."

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell ­