This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: ASCII and BINARY files. Why?


I totally agree.  The ASCII or BINARY thing is no big deal in practice. I 
have ported many Unix programs to DOS and Win95 and usually this is fixed 
by greping for fopen() and open() and making the required mods.  In fact 
the effort expended on this discussion could have been used to sort out a 
couple of utilities in the gnu-win32 package!

Most Unix software which handles text can be made compatible with DOS, 
Win95, WinNT and Unix in very little time this way - it is a shame that 
more Unix programmers don't appreciate this.

-----Original Message-----
From:	Jeffrey C. Fried [SMTP:jcfried@ix.netcom.com]
Sent:	Thursday, January 30, 1997 5:14 PM
To:	GNU-WIN32
Subject:	Re: ASCII and BINARY files. Why?

Grant,

If i've been following this thread correctly, i have to disagree with you.
Over the years i've worked for prolonged periods on 5 different operating
systems (Unix, Primos, VMS, Windows-NT/95/3.1, Exec-8).  Each had its own
way of handling text vs. binary issues.  On 4 of those operating systems i
had access to many, if not all, of the usual Unix text processing tools.
In all cases these tools were adapted so that they utilized the text mode
of the host machine, at least until now with Cygwin-32.  At no time in all
of those cases was my work in any way impeded by the fact that these tools
were only consistently useful on text files.  In fact i know of no one at
any of the very large companies at which i worked who felt any loss because
of this arrangement.  Consistent with that philosophy, please note that GNU
emacs has always worked in the text mode of the operating system under
which it ran (VMS, DOS, Unix, Primos).  And i think that is the approach
which should be taken with respect to Cygwin-32.

It is not a matter of the "average" Win95/NT user, it is a matter for most
of the Win95/NT developers who would like to have access to these tools.
If they have to constantly remember to convert files between the two
environments, they will not use the tools because of the inconvenience and
the tendency to forgot to translate the files into the "current"
environment. While it may be important to you to be able to use these tools
as if you were operating under Unix, i think it is for more important to
most of us that it work within the same environment, producing and
consuming the same files, as the the host OS.

 jeff

At 01:10 AM 1/30/97 -0800, you wrote:
>Grant Leslie wrote:
>>
>> > But not if gnu-win32 goes all-binary-all-the-time, correct?
>> >
>> > I agree that if a friend gives you a text file containing CRNL
>> newline
>> > sequences, then gnu-win32 tools will preserve those ^Ms.  But
>> that's no
>> > different than if you're on a UNIX workstation and someone mails
>> you
>> > such a text file or it you download it via HTTP.  UNIX folks have
>> been
>> > typing
>> >
>> >       tr -d '\015' <dosfile >unixfile
>> >
>> >ever since PCs began connecting to the net.
>>
>> However this step seems a touch superfluous if you are already
>> sitting at a PC, and far from user freindly. If you don't think so
>> try explaining to the "average" Win95 or WinNT user (ok the WinNT
>> user might be MUCH easier) why some of there software works fine,
>> but, if they use this other stuff we made for them that, they need to
>> go to a "DOS prompt" and type this command before they can use the
>> file AND have it look right if they intend to use the stuff you
>> wrote...
>> After all just because we all write this software, lets not forget
>> that it's the end user that has to really get the use out what we
>> make.
>> It just seems to me to just "accept" this is really missing the whole
>> point. No matter what the Text/Binary thing MUST be dealt with one
>> way or another.
>
>You have to accept *some* sort of imperfection.  The argument that users
>shouldn't be made to convert files is useless when the alternative is
>that no tool can be used for both text and binary files.  I want to use
>wc or tr on foo.a as well as foo.b, one a "text" file and one a "data"
>file, both sitting in the same directory.  How do I do that in a
>text/binary mode system?  What about cat foo.[ab] | tr x y | wc?  The
>point here is *critical analysis*, which involves examining tradeoffs.
>Loose talk about "the average Win95 user", a person who would have no
>interest in these tools, ignores the other end, average and not so
>average users who are familiar with these tools and want to fully take
>advantage of their capabilities.
>
>> >If I didn't know better, I'd say Microsoft has _deprectated_
>> >the use of CR in text-files.
>>
>> Now if they had truely done this in say 198? we wouldn't have this
>> problem at all ;-)
>
>If *all* software moved toward treating CR's in text as optional, then
>the problem really would go away, because there would be no reason for
>the library to strip CR's behind the program[mer]'s back.  Note that the
>Java spec defines a line as being terminated by either \n or \r\n.
>
>--
><J Q B>
>-
>For help on using this list, send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>
>
--
Jeffrey C. Fried      jcfried@ix.netcom.com

   Because a liar tells the truth does not mean the truth is a lie.

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]