Subject: RE: Why text=binary mounts
From: [email-masked] (Gary R. Van Sickle)

10 Jan 1998 05:51:15 -0800
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "[email-masked]" <[email-masked]>

Let me start by saying this:  It looks to me we agree almost 100%.  But let 
me address the 'almost':

>> 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!

I agree.  Let's do away with the "b" and the "t" entirely.  All files 
opened by fopen are binary - what you put in is what you get out.

>> 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 :-)

I don't want to start yet another religious war, but the 'get a real OS' 
refrain sounds a lot like the same refrain we used to hear from the Mac 
users.  And the Apple II users.  And the C64 users.  And the Amiga users. 
 (NOTE:  I am not comparing UNIX to any of these systems).  Microsoft is 
winning (in fact has already won) because people hear 'get a real OS' and 
immediately turn off.  People love the underdog, and 'get a real OS' just 
helps the underdog image, regardless of the fact that Microsoft is in no 
real way an underdog.  Furthermore if UNIX is a 'real' OS, why can't the 
UNIX tools accomodate more than one text file format, including my 'poor 
DOS text files'?  PaintShop Pro can manipulate probably 50 different image 
file formats, from PCX for God's sake to PNG, and the user hardly knows the 
difference.

>> 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.

What did I miss here?  GnuWin32 does not include any sort of text proces  
sing library as far as I know.  It deals with the problem by putting in a 
layer *between* the fopen stuff and the OS calls AFAIK, when the solution I 
think you are proposing is a layer *over* the fopen stuff.

>> 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?

I am in no way thinking of breaking the 'UNIX way of computing'!  I just 
don't see why a compiler/make util/etc. shouldn't be able to take any text 
file you throw at it, regardless of which operating system it is running 
on.

>> It may come as a surprise for you that the DOS way is not the right way.

No surprise here.  But please tell me why the UNIX way is the right way. 
 And while we're at it, is JPG the right way, or is PNG the right way? To 
people, text is text.  Why should it not be the same for a 300MHz Pentium 
II.  Or your SparcStation.  Or the Mac.

To badly paraphrase somebody, "The only requirement for evil to succeed is 
for good people to do nothing."  So, gosh darn it, I'm going to try to do 
something.  I propose that I will write a 'text access library' with the 
following features:

1. Written in portable ANSI C (no K&R compilers need apply)
2. Provides all the fscanf, fprintf, etc. (i.e. line reading and writing) 
functionality for text-containing files only
3. Provides some extended, cool features TBD
4. Reads and writes at least UNIX & DOS, maybe HTML, etc. formats later
5. Operates kind of in this wise:  Opens any supported format and they 
behave the same (i.e. 'read line', 'read next char', all retrieve the same 
text regardless of format),  writes

I obviously don't want to do this if nobody will use it, so would/could 
something like this get included in the GNU distribution?  Would somebody 
commit to porting the GNU tools to use it?  Could we get people to actually 
start to deprecate the use of the stdio text-file processing facilities and 
use this library?

Gary R. Van Sickle ([email-masked])
Electrical Design Engineer
Braemar Inc.
11481 Rupp Dr.
Burnsville, MN 55337
(612) 890-5135 Ext. 144
Fax: (612) 882-6550

-----Original Message-----
From:	Tomas Fasth [SMTP:[email-masked]]
Sent:	Friday, January 09, 1998 1:50 PM
To:	[email-masked]
Cc:	Gary R. Van Sickle
Subject:	Re: Why text=binary mounts

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
Mjardevi Science Park           Office tel: +46 13 218 181
Teknikringen 1 E                Office fax: +46 13 218 182
58330 Linkoping                 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".