Subject: Re: Why text=binary mounts
From: [email-masked] (Benjamin Riefenstahl)

17 Jan 1998 12:41:19 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "[email-masked]" <[email-masked]>

Hi Gary,

Gary R. Van Sickle wrote:
> I guess the point I was trying to make is that it doesn't seem to me that
> there is a good argument for there to be text processing functionality in
> the fopen() family of functions (I know, it's a little late now!).

Yeah, that's history, isn't it? fopen() is used for text directly. That
seems to be part of the Unix heritage of C and I would think it does
have it's advantages. After all the vast majority of Unix tools and
Unix-style tools are dealing with text only.

> How about this:  we say, "we're stuck with
> text mode, we'll do better next time, but to alleviate the current
> situation, we take the TAL and put it in the fopen() functions, so that
> when somebody does a fopen(???, "rt"), they are getting the TAL sitting on
> top of a binary stream"?  That way all the old programs which are
> ANSI-compliant (we've canned those that aren't) get the cool new 'any text
> file' functionality *automatically*.  Plus, since the TAL is portable, any
> new GNUWin's or DJGPP's or whatever also get it automatically.  This looks
> to me like it solves the problem in the way you were describing, but
> doesn't require the addition of another mode.

That's basically what I thought. I would try to keep this text mode
layer very simple and small though. When you talk about "TAL" in my mind
I get the image of some library that does all kind of things even
including hooks for stuff like HTML, SGML, and I-don't-know-what-else.
Nice, but I would not want it in the basic RTL. OTOH if we are talking
about ASCII text, with only support for Unix, DOS and Mac line ends,
that would be what I need for ported tools right now. And it's very easy
to implement in just a few lines.

so long, benny
======================================
Benjamin Riefenstahl ([email-masked])
Crocodial Communications EntwicklungsGmbH
Ophagen 16a, D-20257 Hamburg, Germany
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".