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

9 Jan 1998 19:39:23 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
To: "[email-masked]" <[email-masked]>
Cc: "Gary R. Van Sickle" <[email-masked]>

Gary R. Van Sickle wrote:
> 
> This whole UNIX/DOS/text/binary situation drives me nuts.  Why can't this
> problem be solved once and for all by everybody for all time?  We are
> talking about one '\r', for crissake.  What's wrong with this solution:

Gary,

Your solution is wrong because it promotes an out-dated file system
concept originated from digital stoneage operating systems. Back then
fopen("t") ment character (byte) oriented i/o, while fopen("b") ment
block oriented i/o. Back then the choice had an effect on i/o
performance. Now? Heck, modern i/o subsystems are _so_ much more
efficient and clever. Also, memory (good for i/o buffering among other
things) are now-a-days so much more cheap and virtual.

What's wrong with this solution: Do it the Unix way. A file is a file is
a file. Textual end-of-line is not a business of the i/o subsystem. In
Unix the character sequence for end-of-line ('\n' == 012 == 0x10 ==
0b00001100)
is nothing more exciting than a mutual agreement between tools that want
to share text information. How simple!

Ultimately, as a programmer you might want to use a library to share
commonly used text processing. As a bonus the details of certain strange
text processing characteristics (like what sequence of characters to
represent end-of-line) can be hidden from the programmer. Good!

So, a text processing library is the exactly right place for fixes of os
design flaws and differencies such as the use of end-of-line sequence
taking twice as much space as necessary.

Voila! We're back to where we started. GnuWin32.

Please, please, please. Do what you like, but do NOT try to break the
Unix way of computing in the GnuWin32 distribution. If you do, then
what's the point the whole project?

Maybe you're only interested in some groovy tools to filter your poor
DOS text files? My advice: get native ports of those tools. There is no
port? Sad, but you might have to live with that. If you can't, do the
port yourself or switch to a REAL OS (hint: ends with nix :-)

> Let me address one sure-to-come-up complaint right now: the notion that it
> would be too much work to 'fix' all the existing code.  How much time and
> effort is wasted on 'working around' the current situation?  Certainly more
> time than it would take to search-and-replace "w" with "wt", etc.

Oh no. Not in this universe. For reasons too many to list.
It may come as a surprise for you that the DOS way is not the right way.
Life can be cruel sometimes...

-- 
Tomas Fasth                     mailto:[email-masked]
EuroNetics Operation            http://euronetics.com
Mjärdevi Science Park           Office tel: +46 13 218 181
Teknikringen 1 E                Office fax: +46 13 218 182
58330 Linköping                 Mobile tel: +46 708 870 957
Sweden                          Mobile fax: +46 708 870 258
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".