* Re: LF vs. CR/LF (WAS: Problems with libtiff!)
@ 1999-06-21 7:22 Earnie Boyd
1999-06-30 22:10 ` Earnie Boyd
0 siblings, 1 reply; 14+ messages in thread
From: Earnie Boyd @ 1999-06-21 7:22 UTC (permalink / raw)
To: cygwin users
--- Ulrich Koehler <koehler@mvt.tu-clausthal.de> wrote:
> Hello,
>
> first of all: thank you for your help!
> This RTFM! goes to me. I was not aware of the CR/LF
> problem and the differences between text and binary
> mode because I never browsed through the documentation.
> I did not even know that you can open files in text-mode,
> it sounds like a strange idea to me. Because I'm working
> on many platforms, I create and edit only text files with
> UNIX-style line-endings on Windows and I'm trying to keep
> my environment CR/LF-free.
>
Welcome to the world of portable programming.
> Will I experience problems within the cygwin-environment,
> if I use only text=binary mounts?
>
Yes. If the script files contain \r\n line endings then bash and sh will
properly execute them. Don't change to text=binary in order to become lazy. I
always suggest that you leave it witht the text!=binary default.
> BTW:
> I've changed the single open() call in the libtiff-source to
> open the file as binary ( If I remember correctly the value
> O_BINARY is defined, I added '|0x100000' to the mode bits).
> It now seems to work now even with
> my default text!=binary mount. I could compile and link
> my application and used it without problems.
Good.
> I wrote 'it seems to work', because the 'thumbnail' binary
> still does not work. Maybe there is another reason why,
> 'tiff2ps' does work.
If it uses the fopen call you would use "rb" in the function instead of just
"r" to open in binary mode. Unfortunately there isn't a "rt" equivalent for
text mode. You can use though the setmode function to set either _O_BINARY or
_O_TEXT mode after the open call before reading/writing anything into the
buffer.
> I do not have the knowlegde to make a complete port using
> the configure script and I still want to be sure that I did
> the right thing.
I'm just learning the autoconf configure script language myself. Shouldn't be
too difficult to learn. Just start small and grow big.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: LF vs. CR/LF (WAS: Problems with libtiff!)
1999-06-21 7:22 LF vs. CR/LF (WAS: Problems with libtiff!) Earnie Boyd
@ 1999-06-30 22:10 ` Earnie Boyd
0 siblings, 0 replies; 14+ messages in thread
From: Earnie Boyd @ 1999-06-30 22:10 UTC (permalink / raw)
To: cygwin users
--- Ulrich Koehler <koehler@mvt.tu-clausthal.de> wrote:
> Hello,
>
> first of all: thank you for your help!
> This RTFM! goes to me. I was not aware of the CR/LF
> problem and the differences between text and binary
> mode because I never browsed through the documentation.
> I did not even know that you can open files in text-mode,
> it sounds like a strange idea to me. Because I'm working
> on many platforms, I create and edit only text files with
> UNIX-style line-endings on Windows and I'm trying to keep
> my environment CR/LF-free.
>
Welcome to the world of portable programming.
> Will I experience problems within the cygwin-environment,
> if I use only text=binary mounts?
>
Yes. If the script files contain \r\n line endings then bash and sh will
properly execute them. Don't change to text=binary in order to become lazy. I
always suggest that you leave it witht the text!=binary default.
> BTW:
> I've changed the single open() call in the libtiff-source to
> open the file as binary ( If I remember correctly the value
> O_BINARY is defined, I added '|0x100000' to the mode bits).
> It now seems to work now even with
> my default text!=binary mount. I could compile and link
> my application and used it without problems.
Good.
> I wrote 'it seems to work', because the 'thumbnail' binary
> still does not work. Maybe there is another reason why,
> 'tiff2ps' does work.
If it uses the fopen call you would use "rb" in the function instead of just
"r" to open in binary mode. Unfortunately there isn't a "rt" equivalent for
text mode. You can use though the setmode function to set either _O_BINARY or
_O_TEXT mode after the open call before reading/writing anything into the
buffer.
> I do not have the knowlegde to make a complete port using
> the configure script and I still want to be sure that I did
> the right thing.
I'm just learning the autoconf configure script language myself. Shouldn't be
too difficult to learn. Just start small and grow big.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* LF vs. CR/LF (WAS: Problems with libtiff!)
@ 1999-06-30 22:10 Parker, Ron
0 siblings, 0 replies; 14+ messages in thread
From: Parker, Ron @ 1999-06-30 22:10 UTC (permalink / raw)
To: cygwin
Guys, this is the age old CR vs. LF vs. CR/LF argument. In an ideal world
all of the freely available code, most of which was originally written for
UNIX, would specify the proper file open mode.
But to make a point there are cross-platform paradoxes that arise when this
is attempted. Years ago I ported RCS to MS-DOS. At the time I had to
address the CR/LF issues in that package.
Most of the files that are checked into RCS are source files and therefore
contain text, not binary data. So if the local files are opened in
text-mode and the archives are opened in binary-mode, UNIX & MS-OS can share
archive files and still have their proper line ending in their local
sources.
This works wonderfully until a developer checks in a binary file, like TIFF,
BMP, etc. Then the LF->CR/LF mapping that occurs on the MS-OS causes
problems. If the file was checked in from UNIX it breaks on MS-OS and vice
versa.
This one of the reasons why text and binary mode are the same on UNIX, not
to mention that years ago all of the extra CRs added up to wasted storage.
Because of these development issue many of the developers/porters of cygwin
related software continue to use text=binary mounts. This unfortunately
causes the user community much grief, since most of them come from the MS-OS
world.
The purpose of this project is to enable the easy porting of UNIX based
software to the MS-Windows environment. Easy porting does not mean wading
through and "correcting" hundreds of file open commands in a large project.
IMO, this means that software needs to work first in text=binary mode. Then
if a developer has the time to wade through all of the file opens and
correct their mode, wonderful. But only if he can avoid introducing
cross-platform paradoxes and breaking binary files.
PS. MS-OS = MS-DOS or MS-Windows
-----Original Message-----
From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
Sent: Friday, June 18, 1999 1:22 PM
To: itz@lbin.com
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Problems with libtiff!
--- itz@lbin.com wrote:
-8<-
> But this is a development problem, not a usage one. Yes, developers
> and porters should be much more careful about their f?open() calls.
> But where users are concerned, I find it hard to use text mounts (and
> recommend them to other users) when even the most important program of
> them all (bash) is not yet binary/text clean.
If you believe that bash has problems with binary/text then the best
solution
would be to find the problems and submit a patch. BTW, IMO it is readline
that
has the problem and not bash. I've been using cygwin for a couple of years
now
processing with text default mounts and the only problem I've seen with bash
is
the initialization of the history buffer from the history file.
Changing from a default of text mode processing to a default of binary mode
processing only changes the cause of the headaches. You still must properly
port the code. For truly portable code you must specify how the file is to
be
processed before it's processed. DON'T DEPEND ON DEFAULTS.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: LF vs. CR/LF (WAS: Problems with libtiff!)
@ 1999-06-21 9:17 Earnie Boyd
1999-06-30 22:10 ` Earnie Boyd
0 siblings, 1 reply; 14+ messages in thread
From: Earnie Boyd @ 1999-06-21 9:17 UTC (permalink / raw)
To: Peter Ring; +Cc: cygwin users
--- Peter Ring <PRI@cddk.dk> wrote:
> What is the correct way to open, read, and write a 'text' file on a
> filesystem shared between a number of different operating systems?
> (please note that this is in effect what cygwin amounts to).
>
> The scenario could be a 'text' file shared between MacOS, WinNT, and
> some UNIX-like OS. The file might be shared in several ways, some of
> which would make it impractical (if not outright nonsense) to talk about
> one specific OS 'hosting' the file.
>
A good question to ask when wanting to create a multi-platform program that
writes to multi-platform disks. Frankly, in this situation I would open the
file in binary mode, and handle the line formatting characters within the
module. If I were writing a text file from the program I would ensure that the
last character of the line were a null so that the line formatting characters
would be eliminated by default when read.
> Some applications, e.g. emacs, try to guess from the file's content what
> to do. Obviously, this works only for interactive applications.
>
> I won't argue with the benefits of explicitly opening files 'rb'. I just
> wonder why anyone would ever want to do anytning else?
>
To deal with the native tools that exist. E.G.: Notepad (I know, a bad
example, but it's a good bad example) which opens the file in binary mode and
expects to find the \r\n to know when to display on the next line.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: LF vs. CR/LF (WAS: Problems with libtiff!)
1999-06-21 9:17 Earnie Boyd
@ 1999-06-30 22:10 ` Earnie Boyd
0 siblings, 0 replies; 14+ messages in thread
From: Earnie Boyd @ 1999-06-30 22:10 UTC (permalink / raw)
To: Peter Ring; +Cc: cygwin users
--- Peter Ring <PRI@cddk.dk> wrote:
> What is the correct way to open, read, and write a 'text' file on a
> filesystem shared between a number of different operating systems?
> (please note that this is in effect what cygwin amounts to).
>
> The scenario could be a 'text' file shared between MacOS, WinNT, and
> some UNIX-like OS. The file might be shared in several ways, some of
> which would make it impractical (if not outright nonsense) to talk about
> one specific OS 'hosting' the file.
>
A good question to ask when wanting to create a multi-platform program that
writes to multi-platform disks. Frankly, in this situation I would open the
file in binary mode, and handle the line formatting characters within the
module. If I were writing a text file from the program I would ensure that the
last character of the line were a null so that the line formatting characters
would be eliminated by default when read.
> Some applications, e.g. emacs, try to guess from the file's content what
> to do. Obviously, this works only for interactive applications.
>
> I won't argue with the benefits of explicitly opening files 'rb'. I just
> wonder why anyone would ever want to do anytning else?
>
To deal with the native tools that exist. E.G.: Notepad (I know, a bad
example, but it's a good bad example) which opens the file in binary mode and
expects to find the \r\n to know when to display on the next line.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: LF vs. CR/LF (WAS: Problems with libtiff!)
@ 1999-06-21 8:19 Peter Ring
1999-06-30 22:10 ` Peter Ring
0 siblings, 1 reply; 14+ messages in thread
From: Peter Ring @ 1999-06-21 8:19 UTC (permalink / raw)
To: 'earnie_boyd@yahoo.com', 'cygwin users'
What is the correct way to open, read, and write a 'text' file on a
filesystem shared between a number of different operating systems?
(please note that this is in effect what cygwin amounts to).
The scenario could be a 'text' file shared between MacOS, WinNT, and
some UNIX-like OS. The file might be shared in several ways, some of
which would make it impractical (if not outright nonsense) to talk about
one specific OS 'hosting' the file.
Some applications, e.g. emacs, try to guess from the file's content what
to do. Obviously, this works only for interactive applications.
I won't argue with the benefits of explicitly opening files 'rb'. I just
wonder why anyone would ever want to do anytning else?
Kind regards
Peter Ring
-----Original Message-----
From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
Sent: Monday, June 21, 1999 4:29 PM
To: cygwin users
Subject: Re: LF vs. CR/LF (WAS: Problems with libtiff!)
<snip>
Welcome to the world of portable programming.
<snip>
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: LF vs. CR/LF (WAS: Problems with libtiff!)
1999-06-21 8:19 Peter Ring
@ 1999-06-30 22:10 ` Peter Ring
0 siblings, 0 replies; 14+ messages in thread
From: Peter Ring @ 1999-06-30 22:10 UTC (permalink / raw)
To: 'earnie_boyd@yahoo.com', 'cygwin users'
What is the correct way to open, read, and write a 'text' file on a
filesystem shared between a number of different operating systems?
(please note that this is in effect what cygwin amounts to).
The scenario could be a 'text' file shared between MacOS, WinNT, and
some UNIX-like OS. The file might be shared in several ways, some of
which would make it impractical (if not outright nonsense) to talk about
one specific OS 'hosting' the file.
Some applications, e.g. emacs, try to guess from the file's content what
to do. Obviously, this works only for interactive applications.
I won't argue with the benefits of explicitly opening files 'rb'. I just
wonder why anyone would ever want to do anytning else?
Kind regards
Peter Ring
-----Original Message-----
From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
Sent: Monday, June 21, 1999 4:29 PM
To: cygwin users
Subject: Re: LF vs. CR/LF (WAS: Problems with libtiff!)
<snip>
Welcome to the world of portable programming.
<snip>
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: LF vs. CR/LF (WAS: Problems with libtiff!)
@ 1999-06-21 7:10 Earnie Boyd
1999-06-30 22:10 ` Earnie Boyd
0 siblings, 1 reply; 14+ messages in thread
From: Earnie Boyd @ 1999-06-21 7:10 UTC (permalink / raw)
To: Demmer, Thomas; +Cc: cygwin users
--- "Demmer, Thomas" <TDemmer@kjs.com> wrote:
> Just to add my 2 cents to that:
> The source of the zip program suite shows a quite nice way
> how to handle that difference on various platforms. Should be
> mandatory for all ports ;-)
Would this be gzip? or some other package?
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: LF vs. CR/LF (WAS: Problems with libtiff!)
1999-06-21 7:10 Earnie Boyd
@ 1999-06-30 22:10 ` Earnie Boyd
0 siblings, 0 replies; 14+ messages in thread
From: Earnie Boyd @ 1999-06-30 22:10 UTC (permalink / raw)
To: Demmer, Thomas; +Cc: cygwin users
--- "Demmer, Thomas" <TDemmer@kjs.com> wrote:
> Just to add my 2 cents to that:
> The source of the zip program suite shows a quite nice way
> how to handle that difference on various platforms. Should be
> mandatory for all ports ;-)
Would this be gzip? or some other package?
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: LF vs. CR/LF (WAS: Problems with libtiff!)
@ 1999-06-21 5:10 Demmer, Thomas
1999-06-30 22:10 ` Demmer, Thomas
0 siblings, 1 reply; 14+ messages in thread
From: Demmer, Thomas @ 1999-06-21 5:10 UTC (permalink / raw)
To: 'Ulrich Koehler', cygwin
Just to add my 2 cents to that:
The source of the zip program suite shows a quite nice way
how to handle that difference on various platforms. Should be
mandatory for all ports ;-)
Ciao
Tom
> -----Original Message-----
> From: Ulrich Koehler [SMTP:koehler@mvt.tu-clausthal.de]
> Sent: Monday, June 21, 1999 1:01 PM
> To: cygwin@sourceware.cygnus.com
> Subject: LF vs. CR/LF (WAS: Problems with libtiff!)
>
> Hello,
>
> first of all: thank you for your help!
> This RTFM! goes to me. I was not aware of the CR/LF
> problem and the differences between text and binary
> mode because I never browsed through the documentation.
> I did not even know that you can open files in text-mode,
> it sounds like a strange idea to me. Because I'm working
> on many platforms, I create and edit only text files with
> UNIX-style line-endings on Windows and I'm trying to keep
> my environment CR/LF-free.
>
> Will I experience problems within the cygwin-environment,
> if I use only text=binary mounts?
>
> BTW:
> I've changed the single open() call in the libtiff-source to
> open the file as binary ( If I remember correctly the value
> O_BINARY is defined, I added '|0x100000' to the mode bits).
> It now seems to work now even with
> my default text!=binary mount. I could compile and link
> my application and used it without problems.
> I wrote 'it seems to work', because the 'thumbnail' binary
> still does not work. Maybe there is another reason why,
> 'tiff2ps' does work.
> I do not have the knowlegde to make a complete port using
> the configure script and I still want to be sure that I did
> the right thing.
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: LF vs. CR/LF (WAS: Problems with libtiff!)
1999-06-21 5:10 Demmer, Thomas
@ 1999-06-30 22:10 ` Demmer, Thomas
0 siblings, 0 replies; 14+ messages in thread
From: Demmer, Thomas @ 1999-06-30 22:10 UTC (permalink / raw)
To: 'Ulrich Koehler', cygwin
Just to add my 2 cents to that:
The source of the zip program suite shows a quite nice way
how to handle that difference on various platforms. Should be
mandatory for all ports ;-)
Ciao
Tom
> -----Original Message-----
> From: Ulrich Koehler [SMTP:koehler@mvt.tu-clausthal.de]
> Sent: Monday, June 21, 1999 1:01 PM
> To: cygwin@sourceware.cygnus.com
> Subject: LF vs. CR/LF (WAS: Problems with libtiff!)
>
> Hello,
>
> first of all: thank you for your help!
> This RTFM! goes to me. I was not aware of the CR/LF
> problem and the differences between text and binary
> mode because I never browsed through the documentation.
> I did not even know that you can open files in text-mode,
> it sounds like a strange idea to me. Because I'm working
> on many platforms, I create and edit only text files with
> UNIX-style line-endings on Windows and I'm trying to keep
> my environment CR/LF-free.
>
> Will I experience problems within the cygwin-environment,
> if I use only text=binary mounts?
>
> BTW:
> I've changed the single open() call in the libtiff-source to
> open the file as binary ( If I remember correctly the value
> O_BINARY is defined, I added '|0x100000' to the mode bits).
> It now seems to work now even with
> my default text!=binary mount. I could compile and link
> my application and used it without problems.
> I wrote 'it seems to work', because the 'thumbnail' binary
> still does not work. Maybe there is another reason why,
> 'tiff2ps' does work.
> I do not have the knowlegde to make a complete port using
> the configure script and I still want to be sure that I did
> the right thing.
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* LF vs. CR/LF (WAS: Problems with libtiff!)
@ 1999-06-21 5:02 Ulrich Koehler
1999-06-30 22:10 ` Ulrich Koehler
0 siblings, 1 reply; 14+ messages in thread
From: Ulrich Koehler @ 1999-06-21 5:02 UTC (permalink / raw)
To: cygwin
Hello,
first of all: thank you for your help!
This RTFM! goes to me. I was not aware of the CR/LF
problem and the differences between text and binary
mode because I never browsed through the documentation.
I did not even know that you can open files in text-mode,
it sounds like a strange idea to me. Because I'm working
on many platforms, I create and edit only text files with
UNIX-style line-endings on Windows and I'm trying to keep
my environment CR/LF-free.
Will I experience problems within the cygwin-environment,
if I use only text=binary mounts?
BTW:
I've changed the single open() call in the libtiff-source to
open the file as binary ( If I remember correctly the value
O_BINARY is defined, I added '|0x100000' to the mode bits).
It now seems to work now even with
my default text!=binary mount. I could compile and link
my application and used it without problems.
I wrote 'it seems to work', because the 'thumbnail' binary
still does not work. Maybe there is another reason why,
'tiff2ps' does work.
I do not have the knowlegde to make a complete port using
the configure script and I still want to be sure that I did
the right thing.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* LF vs. CR/LF (WAS: Problems with libtiff!)
1999-06-21 5:02 Ulrich Koehler
@ 1999-06-30 22:10 ` Ulrich Koehler
0 siblings, 0 replies; 14+ messages in thread
From: Ulrich Koehler @ 1999-06-30 22:10 UTC (permalink / raw)
To: cygwin
Hello,
first of all: thank you for your help!
This RTFM! goes to me. I was not aware of the CR/LF
problem and the differences between text and binary
mode because I never browsed through the documentation.
I did not even know that you can open files in text-mode,
it sounds like a strange idea to me. Because I'm working
on many platforms, I create and edit only text files with
UNIX-style line-endings on Windows and I'm trying to keep
my environment CR/LF-free.
Will I experience problems within the cygwin-environment,
if I use only text=binary mounts?
BTW:
I've changed the single open() call in the libtiff-source to
open the file as binary ( If I remember correctly the value
O_BINARY is defined, I added '|0x100000' to the mode bits).
It now seems to work now even with
my default text!=binary mount. I could compile and link
my application and used it without problems.
I wrote 'it seems to work', because the 'thumbnail' binary
still does not work. Maybe there is another reason why,
'tiff2ps' does work.
I do not have the knowlegde to make a complete port using
the configure script and I still want to be sure that I did
the right thing.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* LF vs. CR/LF (WAS: Problems with libtiff!)
@ 1999-06-18 12:14 Parker, Ron
0 siblings, 0 replies; 14+ messages in thread
From: Parker, Ron @ 1999-06-18 12:14 UTC (permalink / raw)
To: cygwin
Guys, this is the age old CR vs. LF vs. CR/LF argument. In an ideal world
all of the freely available code, most of which was originally written for
UNIX, would specify the proper file open mode.
But to make a point there are cross-platform paradoxes that arise when this
is attempted. Years ago I ported RCS to MS-DOS. At the time I had to
address the CR/LF issues in that package.
Most of the files that are checked into RCS are source files and therefore
contain text, not binary data. So if the local files are opened in
text-mode and the archives are opened in binary-mode, UNIX & MS-OS can share
archive files and still have their proper line ending in their local
sources.
This works wonderfully until a developer checks in a binary file, like TIFF,
BMP, etc. Then the LF->CR/LF mapping that occurs on the MS-OS causes
problems. If the file was checked in from UNIX it breaks on MS-OS and vice
versa.
This one of the reasons why text and binary mode are the same on UNIX, not
to mention that years ago all of the extra CRs added up to wasted storage.
Because of these development issue many of the developers/porters of cygwin
related software continue to use text=binary mounts. This unfortunately
causes the user community much grief, since most of them come from the MS-OS
world.
The purpose of this project is to enable the easy porting of UNIX based
software to the MS-Windows environment. Easy porting does not mean wading
through and "correcting" hundreds of file open commands in a large project.
IMO, this means that software needs to work first in text=binary mode. Then
if a developer has the time to wade through all of the file opens and
correct their mode, wonderful. But only if he can avoid introducing
cross-platform paradoxes and breaking binary files.
PS. MS-OS = MS-DOS or MS-Windows
-----Original Message-----
From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
Sent: Friday, June 18, 1999 1:22 PM
To: itz@lbin.com
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Problems with libtiff!
--- itz@lbin.com wrote:
-8<-
> But this is a development problem, not a usage one. Yes, developers
> and porters should be much more careful about their f?open() calls.
> But where users are concerned, I find it hard to use text mounts (and
> recommend them to other users) when even the most important program of
> them all (bash) is not yet binary/text clean.
If you believe that bash has problems with binary/text then the best
solution
would be to find the problems and submit a patch. BTW, IMO it is readline
that
has the problem and not bash. I've been using cygwin for a couple of years
now
processing with text default mounts and the only problem I've seen with bash
is
the initialization of the history buffer from the history file.
Changing from a default of text mode processing to a default of binary mode
processing only changes the cause of the headaches. You still must properly
port the code. For truly portable code you must specify how the file is to
be
processed before it's processed. DON'T DEPEND ON DEFAULTS.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1999-06-30 22:10 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-21 7:22 LF vs. CR/LF (WAS: Problems with libtiff!) Earnie Boyd
1999-06-30 22:10 ` Earnie Boyd
-- strict thread matches above, loose matches on Subject: below --
1999-06-30 22:10 Parker, Ron
1999-06-21 9:17 Earnie Boyd
1999-06-30 22:10 ` Earnie Boyd
1999-06-21 8:19 Peter Ring
1999-06-30 22:10 ` Peter Ring
1999-06-21 7:10 Earnie Boyd
1999-06-30 22:10 ` Earnie Boyd
1999-06-21 5:10 Demmer, Thomas
1999-06-30 22:10 ` Demmer, Thomas
1999-06-21 5:02 Ulrich Koehler
1999-06-30 22:10 ` Ulrich Koehler
1999-06-18 12:14 Parker, Ron
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).