RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Earnie Boyd <earnie_boyd at yahoo dot com>]

I don't know exactly where to begin, I'm having trouble formulating any
connected thoughts on this.  So let me try to summarize:

1) MSDOS/WIN32 has two file processing modes that produce two different line
   endings.
   A) Normal default is "Text Mode".
   B) Default can be changed just by adding an object that does nothing except
      sets the default value of the external variable _filemode.
   C) File processing mode can be explicit set.

2) Cygwin tries to emulate as much of UNIX as possible but must live within
   the given MSDOS/WIN32 environment.
   A) Gives the users a choice about what the default processing mode should be
      for a given "mount point".
   B) Provides objects to set the external _filemode variable.
   C) Provides defaults via the [no]binmode CYGWIN setting for the Non-Cygwin
      shells for piping and redirection.
   D) Provides the POSIX runtime to allow UNIX programs to be "ported" easily
      to the Win32 platform.

3) There are a wide variety of users.
   A) Strong in UNIX forced to use Win32
   B) Strong in Win32 and want to learn UNIX
   C) Just want to learn programming and don't have thousands of dollars to
      spend in software.
   D) The student who knows little about computing and just wants to get the
      assignment completed.

4) A wide variety of expectations for Cygwin.
   A) Behave exactly like UNIX.
   B) Behave exactly like MSDOS/WIN32.
   C) Take care of all of the idiosyncracies of the differences between UNIX
      and MSDOS/WIN32.
   D) Make the job easier without me doing any of the work.
   E) Someone else fix all of the bugs. ;)

5) UNIX and Unix programs don't handle the \r line ending.
   A) CR/LF problems exist in the UNIX environment.
   B) In UNIX one has to filter a file of \r\n to remove the \r before
      processing it.
   C) 99.9% of the Win32 programs understand files with the \n line endings.
      (NOTEPAD is the only program that I know that can't).

Given the above (and probably some items I've missed) what conclusions can we
come to about how Cygwin should treat the CR/LF line endings vs how the tools
should be ported to treat the CR/LF line endings?

I don't know that I can sanely draw a conclusion.  I myself use binary mounts
and translate any files that aren't UNIX compatible just as I would on UNIX. 
Should we modify the textutils family (this includes cat) to open the files
specifically in binary mode regardless of the mount point setting?  Well, IMO,
I don't think we should.  Should we add --text, --binary and --mixed switches
to the programs themselves?  IMO, yes we should.  Should the official release
of the GNU package contain these switches?  Well, they would be useful even on
UNIX if properly designed, so yes patches should be submitted to the package
maintainer.

So: 
Should we revert the change to cat?  Yes.

Should we add --text, --binary and --mixed switches to cat and any other
utility?  Yes.

Are there other changes with regard to CR/LF line endings?  Yes.

1) I would like for the mount command to default the file processing mode to
   whatever I have the root mount point set.  I.E. if / is text mode then
   set the new mount point unless specified to text mode and vice versa.

2) Change setup (and it may already do this) so that the /cygdrive prefix 
   default file processing mode is based on the chosen file processing mode.

3) Add a mixed file processing mode to the Cygwin mount table.
   (Mixed file processing would read in text mode and write in binary mode.)

Cheers,

=====
--- <http://earniesystems.safeshopper.com> ---
   Earnie Boyd: <mailto:earnie_boyd@yahoo.com>
            __Cygwin: POSIX on Windows__
Cygwin Newbies: <http://gw32.freeyellow.com/>
           __Minimalist GNU for Windows__
    Mingw Home: <http://www.mingw.org/>

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com