Re: line endings in text files and -kb

[Todd Denniston]

Ittay Dror wrote, On 09/11/2008 12:14 PM:
> Larry Jones wrote:
> > Ittay Dror writes:
> >  
> > >  
> > > well, i created a file named test.sh, marked it as -kb, made some 
> > > changes
> > > and commits and on the server side, test.sh,v appeared to have each 
> > > commit
> > > as the full file, not a diff.     
> >
> > Like I said, diff doesn't usually work very well on binary files.
> >   
> like i said, the file is a text file, it is just marked with -kb so cvs 
> will not modify line endings.

On windows, are you using cvs under cygwin or CVSNT?
If under cygwin, then is the text file in a cygwin text or binary mount?
[answering these questions will help everyone get you the correct answers, 
i.e, they matter to the subject area you are asking about.]

BTW if you are collaborating with other windows users, are any of them using 
the other product or using cygwin mounts differently?


> >  
> > > and if my file is not binary (test.sh), but is marked as -kb, will 
> > > CVS try
> > > to merge it?     
> >
> > CVS has no way to know whether your file is "really" binary or not -- if
> > you tell CVS it's a binary file, then it will be treated as a binary
> > file and will not merge it.
> >   
> yes, but why can't i just say: "don't modify line endings" without 
> meaning the file is binary?

what is your intentions of "don't modify line endings"?

windows programs interpret text files different than Unix programs interpret 
text files, and cvs knows how and when to do the translation of text files, 
that it has not been told are binary.  Usually folks WANT the translation, 
that is why good ftp clients let you tell them you are transferring text files 
so that the client and server can negotiate any needed translation.

> >  
> > > i don't. i want to prevent CVS from converting line endings. the file is
> > > checked out in windows but is later used in linux (it is part of a 
> > > product
> > > build), but because CVS converts line endings, i get a '/bin/bash^M: bad
> > > interpreter error'
> > >     
> >
> > That's not CVS's fault.  If you want to use the file on Linux, you
> >   
> oh, it is, because cvs decided to change the file without giving me a 
> reasonable way to tell it not to.

Quite the opposite, YOU told cvs (via -kb) not to change the file, and it 
obeyed, i.e., you added the file with -kb and then committed it from MS, and 
on MS the file contained "/bin/bash^M", and because of the -kb, cvs on Linux 
gave you EXACTLY the file committed on the MS machine which contains "/bin/bash^M"

You do understand that the ends of lines created by _most_ text editing 
products on Microsoft OS's use CRLF (shown on Unix as "^M"), and unless you 
tell UNIX text editing/interpreting products to do otherwise they use LF?

If you DON'T use -kb, and you do use CVS[NT] in the correct ways (usually the 
default way), then cvs will take care of the CRLF - LF difference for you.



an experiment for you:
on Unix in your sandbox take your test.sh script and run

cat test.sh |  \
 tr -d "\r" >tmpfile; \
 mv tmpfile test.sh; \
 cp test.sh test2.sh; \
 cvs add -m"no kb" test2.sh; \
 cvs commit -m"no kb" test2.sh

then `cvs commit test.sh`
now on windows `cvs update test.sh test2.sh` and then open the test.sh file in 
your text editor.
I expect you will see everything on one line, and sometimes it will have a box 
at the place you expect to see the effect of Enter being pressed.
if you open test.sh with the same editor, you should see everything as you 
would expect, i.e. correct.

> > should check it out on Linux.  If you can't do that for some reason,
> > then you need to transfer the file using something that converts the
> > line endings correctly.
> >   


--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter