Mail Archives: cygwin/1997/01/30/03:22:12
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 AT cygnus DOT com" with one line of text: "help".
- Raw text -