[mingw32] Re: ANNOUNCE selfhosting mingw32
Mon Dec 20 07:57:00 GMT 1999
--- Mikey <firstname.lastname@example.org> wrote:
> On Sun, 19 Dec 1999 08:09:08 -0800 (PST), you wrote:
> >> This is kind of an expansion on what Earnie
> >> did for with mingw32-sup.1.0, except he and I disagree
> >> on binary/text mode issues in the development tools.
> >Could you please remind me of what our differences are? Mainly so I can
> No need to defend it's just a difference of opinion.
Well, defend might be the incorrect word, how about clarify.
> Under cygwin, you always seem to feel that binary mounts (forced binary file
> opens) are not the right way to go, and that to be "properly" ported an
> executable must make special accommodations to handle "TEXT" specially,
> --binary flags for cat, and so on.
My position about the Cygwin binary vs text mounts is totally based on ease of
use of the Cygwin product. The net releases contained the \r\n when unpacked
and it just made since to suggest text mounts. My position has changed
somewhat to be it depends on the need, such that, if you're textfiles are
crossing platforms then binary mounts for the net devices are the correct
choice. I've always said, specify the correct file processing mode and don't
depend on the defaults. Files should be opened in binary mode unless the file
has the possibility of being created by humans using a text editor such as
Notepad. The other way to handle \r\n is to open in binary mode and strip the
\r from the end of the line yourself.
As for the --binary flag, it was not me who suggested that as far as I
remember. I may have been in agreement that it was a method for handling it, I
don't think it is the best method. The main reason that the files have the
\r\n endings is so that lines are displayed beginning in column 1. On *nix,
the terminal support adds the \r for the \n given, where as in DOS/WIN32 it is
the output functions themselves that support this.
> Where I think that this is a waste of time, and that forcing all ported unix
> programs to use binary opens for all files, including stdin/out/err where
> appropriate FOR THE GNU DEVELOPMENT TOOLS will only reduce confusion when
> exchanging sources/patches with people on un*x hosts.
I don't disagree with this point at all. I think that a method of determining
the file type automatically would be desirable. If the file has \r\n line
endings then read it as text. If the file has \n line endings then read it as
binary file. If the file has \r line endings then convert the \r (Mac Style)
then convert the \r to \n. In all cases the write should always be specified
> MS tools ie vc++/nmake can handle either \n or \r\n
> in headers/sources/makefiles.
The only program that I'm aware of that can't handle the \n line endings is
Notepad. The reason is that it opens the file in binary processing mode and if
it doesn't have the \r in the file it doesn't know when to go to column 1.
> >> makeinfo-1.68 from texinfo-3.12
> >> Thanks in no particular order are due to
> >> Geoff Noer, Mumit Kahn, and Earnie Boyd,
> >> for inspiring me to finally get off my A*S
> >> and do something about it.
> >You're welcome. This is a welcome package. I'm assuming that none of this
> >uses the Cygwin dll, I'm I correct on this.
> >> (should make for easier use under command.com/cmd.exe)
> >Wow, Mikey, you sure have a lot of work here. I was actually thinking of
> >actively doing something like this. It looks like you've beat me to the
> >Please note: there is an active Mingw32 list mingw32@eGroups.com where you
> >should also post this.
> Been there, done that ;-), going back for the T shirt.
Yea, I realized that when I went to the Mingw32 folder.
Earnie Boyd < mailto:email@example.com >
Cygwin Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org
More information about the Cygwin