Mail Archives: cygwin/1998/01/10/05:51:15
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 (tiberius AT braemarinc DOT com)
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:tomas DOT fasth AT twinspot DOT net]
Sent: Friday, January 09, 1998 1:50 PM
To: gnu-win32 AT cygnus DOT com
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:tomas DOT fasth AT euronetics DOT com
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
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -