[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: line endings in text files and -kb
From: |
Ittay Dror |
Subject: |
Re: line endings in text files and -kb |
Date: |
Thu, 11 Sep 2008 20:39:22 +0300 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080724) |
Todd Denniston wrote:
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?
turtoise cvs
If under cygwin, then is the text file in a cygwin text or binary mount?
not sure what you mean
[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.
ok, but in this case i'm not editing the file, i'm just moving it around
to create a product tree. someone else edited it and committed and the
build just so happens to run on windows. also, afaik, most windows ides
(outside of notepad) know how to handle just \n today.
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"
what happened is this:
- there was no -kb
- a developer checks out the source tree and works with it, making some
changes to .c files
- not touching the file in question. the file is a startup script for
a daemon
- the build is ok on windows, so now he wants to check it is ok on linux
- we don't want him to commit in order to test.
- so, he mounts the source tree from a linux machine and runs the build
- this copies the file to the output of the build
- he wants to test the daemon, so he runs the startup script (the file
in question)
--> this fails. the file was checked out in windows, so now it has ^M
there is now the option to mark the file with -kb, thus solving the
issue above, but merging will not work
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?
yes, it is the developer's responsibility to commit after dos2unix. in
any case, even if he forgets, it is easy to fix (checkout, remove, commit)
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.
i'm sure both eclipse and visual studio will handle the file just fine.
i also think that 'writer' handles such files fine.
ittay
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.
--
--
Ittay Dror <address@hidden>
- line endings in text files and -kb, Ittay Dror, 2008/09/10
- Re: line endings in text files and -kb, Larry Jones, 2008/09/11
- Re: line endings in text files and -kb, Ittay Dror, 2008/09/11
- Re: line endings in text files and -kb, Larry Jones, 2008/09/11
- Re: line endings in text files and -kb, Ittay Dror, 2008/09/11
- Re: line endings in text files and -kb, Todd Denniston, 2008/09/11
- Re: line endings in text files and -kb,
Ittay Dror <=
- Re: line endings in text files and -kb, Paul Sander, 2008/09/11
- Re: line endings in text files and -kb, Ittay Dror, 2008/09/11
- Re: line endings in text files and -kb, Paul Sander, 2008/09/11
- Re: line endings in text files and -kb, Todd Denniston, 2008/09/11
- Re: line endings in text files and -kb, Ittay Dror, 2008/09/11
- Re: line endings in text files and -kb, Spiro Trikaliotis, 2008/09/12