Re: encapsulating directory operations

On 2025-05-23, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

"Paul Edwards" <mutazilah@gmail.com> writes:

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a575zvmb.fsf@nosuchdomain.example.com...
>

I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.

>
But there's no such thing.  I recall looking into this last time we
discussed this, and ANSI X3.64 is defined in terms of ASCII.

>
I didn't fully answer this either.
>
Yes, if you want to be pedantic, the ANSI X3.64 uses the
word ASCII, because they didn't spend any effort considering
that someone might want to do exactly the same thing on an
EBCDIC system - in the future - because there was no such
thing in existence at that time.
>
But if that committee had spent the effort to consider EBCDIC,
they probably would have reworded the language.

>
I believe that is unfounded speculation.  I'm nearly certain that
the designers of ANSI X3.64 were aware of EBCDIC.  We know that
they wrote a standard that depends on ASCII and not on EBCDIC.
I presume this was an entirely deliberate choice, not an unfortunate
oversight that they would have reconsidered if they had only taken
a moment to think about it.

ANSI X3.64 an adopted an existing standard called ECMA-48. The ECMA-48
people probably based on ASCII because it was a continuation in a series
of ECMA standards in the area of character sets. Before that they
produced ECMA-6, related to ASCII, which went on to become ISO 646.

Why would their terminal control standard cater to a character
set unrelated to one they had invented, right?

From their point of view, EBCDIC would likely have appeared as a
nonstandard, vendor-specific character coding method, off-topic to their
character set standardization efforts.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca