"Doug Ewell" <[email protected]> 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
--- Begin Message ---
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
--- End Message ---
