Am 22.08.14 01:56, schrieb Glenn Linderman:
0 and 47 are certainly originally derived from ASCII. However, there
could be lots of encodings that are not ASCII compatible (but in
practice, probably very few, since most encodings _are_ ASCII
compatible) that could be fit those constraints.

So while as a technical matter, Cameron is correct that Unix only treats
0 & 47 as special, and that is insufficient to declare that encodings
must be ASCII compatible, as a practical matter, since most encodings
are ASCII compatible anyway, it would be hard to find very many that
could be used successfully with Unix file names that are not ASCII
compatible, that could comply with the 0 & 47 requirements.

More importantly, existing encodings that are distinctively *not*
ASCII compatible (e.g. the EBCDIC ones) do not put the slash into 47
(instead, it is at 91 at EBCDIC, 47 is the BEL control character).

There are boundary cases, of course. VISCII is "mostly ASCII
compatible", putting graphic characters into some of the control
characters, but using those that aren't used in ASCII, anyway.

And then there is the YUSCII family of encodings, which definitely
is not ASCII compatible, as it does not contain Latin characters,
but still puts the / into 47 (and also keeps the ASCII digits and
special characters in their positions). There is also SI 960, which
has the slash, the ASCII uppercase letters, digits and special
characters, but replaces the lower-case characters with Hebrew.

So yes, Unix doesn't mandate ASCII-compatible encodings; but it
still mandates ASCII-inspired encodings. I wonder how you would
run "gcc", though, on an SI 960 system; you'ld have to type


Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2017 Grokbase