Subject: vim oddities (this message is somewhat verbose)
From: [email-masked] (Christopher Murray)

23 Jan 1999 20:21:45 -0800
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [email-masked]

Hi there,

I have 2 vim oddities to report for the port that I downloaded from
ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin32/porters/Hirmke_Mich
ael/B20/
(They also happen when I build them myself)

My typical mode of operations is using vim in a console mode within a tcsh
window.  

1)  When I start up vim in console mode, a WINNT dialog box pops up
prompting me that I am not
dialed in to my ISP and would I like dial in to establish the connection.
I would expect this 
sort of behavior from Netscape or Eudora if I tried to open them up without
being dialed in 
first, but vim????  I believe there is an option in NT somewhere that will
turn this behavior
off, but the point is, I shouldn't have to.

2)  When I try to edit text files in console mode that were generated by
Windows Programs,  I 
get those stupid ^M's at the end of the line.  (When using the GUI version
of vim, the 
problem disappears).  I have tried all combinations of setting binary
mounts & the binmode
flag (also, I always set variables via WINNT system properties, then spawn
the shell, then vim, this way
I am sure the environment variables are properly inherited).  At any rate,
nothing has any effect.

OK, so it must be deeper level of porting problem.  My trouble is two-fold - 

1)  I am a FORTRAN programmer and don't understand C all that well
2)  My understanding of how this binary mode/text mode thing really works
is apparently not as good
    as I thought it was

My understanding of the binary and text processing is this (could someone
please correct me if I am wrong?):

1)  All writes to disk by DOS/WINDOWS programs, whether they be binary or
ascii text files, sticks two characters at the end of each line, \r\n, and
these characters are actually stored along with the rest of the file, when
the file is saved to disk.  This happens at the level of the I/O libraries
in the compiler.
On the other hand, files generated by UNIX stick just the \n at the end of
each line, no matter if the file is binary or text.

2)  When a C program places a call to fopen, so that the file may either be
read from or written to, the programmer can opt to pass the "b" flag,
telling it to treat the file as a binary file (i.e. won't account for a \r
if it is there).  If the "b" is not passed (default), it strips out the \r
as lines are read, and all is hunky dory.  If the \r is not there, then the
fopen call still behaves the same - it just didn't go that extra step to
strip out the \r.  

If the "b" is passed, then the fopen is essentially being told the file
WILL be binary (i.e. no \r) and only a \n should be expected.  So when \r's
are there, everything gets screwed up because the fopen expects only a \n,
but that one extra byte is in there when it shouldn't (which is why fseek,
etc have trouble - the byte counts are worng)

3)  Now having said this, an editor like vim would I suspect try to open up
files without the "b" flag, indicating that in a DOS environment, the \r
gets stripped by default if it is there.  A check of all the
"open" calls indicates that the binary mode flag is not passed.  So what
gives?  Why does it show the 
^M's ??  

I am severely missing something.  Not understanding C all that well, I have
tried modifying those calls to open
that I think are the ones that open up files given at the command line, but
I can't get things to work.

Can someone out there who is more knowledgeable than I please help?

Thank you very much for being patient enough to read all this text.
Chris 

***************************************************************************
Christopher Murray			Applied Research Laboratory
Assistant Research Engineer		The Pennsylvania State University
Work Phone:  (814) 865-2016		P.O. Box 30
Home Phone: (814) 231-2125		State College, PA 16804
Work Fax: (814) 863-1479 		Email: [email-masked]
v1.2a r+d>s TW 1/0/pw tG 12? 0 Animals 3 2 57.5% <16dec98>
***************************************************************************

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".