From: Peter Ring <PRI@cddk.dk>
To: 'Fergus Henderson' <fjh@cs.mu.OZ.AU>,
"'cygwin@sourceware.cygnus.com'" <cygwin@sourceware.cygnus.com>
Subject: RE: text vs binary mode yet again
Date: Wed, 31 Mar 1999 19:45:00 -0000 [thread overview]
Message-ID: <c=DK%a=_%p=CD-Danmark%l=CDDKSERVER-990310142043Z-4071@cddkserver.cddk.dk> (raw)
Message-ID: <19990331194500.uv60vMzsVketNhq1GdMgO1IrS87YRFPCL9AW_7Sgafs@z> (raw)
I use cygwin and Gnu tools because I need the functionality that
fileutils, textutils et al. provides, but on a Windows NT box.
And I prefer tar, cat and pipes not to mess with the contents
of my files except when told to.
Problems are no better or worse on Linux. Well, perhaps a bit worse,
since Windows NT has quite good Unicode support. Windows application
are in general better at supporting 'foreign' conventions than
either MacOS or Unix applications (with some editors like Emacs as
notable exceptions).
But you miss the point completely. In a mixed file system environment,
applications have no way of inferring which convention to follow re.
linebreaks, except not to mess them up. I.e., if a 'text' file appears
to use \xA as record separator, write that; if \xD\xA, write that;
if \xD, write that. For new files, you have to ask the user or infer
from a broader context than 'the current OS'.
BTW, if you are told that a file is a 'text' file, which encoding do
you expect it to use ?
7-bit encoding, ISO 646-1973 IRV (any other in widespread use?)
8-bit encoding, UTF-8, IBM CP-437, MS CP-1252, ISO Latin 1..n, etc.
16-bit encoding, UTF-16, various Japaneese, Chinese, Korean etc.
IMHO, the only thing that 'text' files have in common is that you
can expect some sort of record separator.
Kind regards
Peter Ring
-----Original Message-----
From: Fergus Henderson [ mailto:fjh@cs.mu.OZ.AU ]
Sent: Wednesday, March 10, 1999 01:13
To: cygwin@sourceware.cygnus.com
Subject: text vs binary mode yet again
<snip>
If you're using cygwin at all, it's presumably because compatibility
with existing software is of some concern. Otherwise, just use Linux!
> >> Why should I want to open a file in 'text' mode? What if I run
> >> a cygwin application to write a 'text' file that is part of a
> >> MacOS application? I need three different record separators,
> >> and I can't infer which to use just from what OS the
> >> application is running on. BTW, this is an actual example of
> >> what I use cygwin tools for.
In that particular case, you wouldn't want to open the file in text
mode.
But there are plenty of other cases where text mode does make sense.
<snip>
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
next reply other threads:[~1999-03-31 19:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-10 6:21 Peter Ring [this message]
1999-03-31 19:45 ` Peter Ring
-- strict thread matches above, loose matches on Subject: below --
1999-03-09 7:58 ÃANNÃ Cygwin DEV survey Peter Ring
1999-03-09 10:02 ` _FANNE_Cygwin_DEV_survey Dr. Volker Zell
[not found] ` < 4798-Tue09Mar1999190417+0100-vzell@de.oracle.com >
1999-03-09 16:13 ` text vs binary mode yet again Fergus Henderson
1999-03-31 19:45 ` Fergus Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='c=DK%a=_%p=CD-Danmark%l=CDDKSERVER-990310142043Z-4071@cddkserver.cddk.dk' \
--to=pri@cddk.dk \
--cc=cygwin@sourceware.cygnus.com \
--cc=fjh@cs.mu.OZ.AU \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).