Jeremias Maerki wrote:
up a few patch submissions. While applying them I ran across several
files that had CRCRLF endings instead of CRLF when checked out using
WinCVS on a Windows box. I think I have successfully corrected those I
ran into. Does anyone have a good idea how to...
1. identify
Thanks for your input. Your suggestion below smells dangerous, though.
In the meantime I've started a little check-program (in Java) that
analyzes files on their line endings using regex-matching. I think, I'll
expand that to a little project including command-line app, ant-task etc.
On Tue, 5
Victor Mote wrote:
Also, if you want to clean up the files in the repository, I understand that
running cvs admin -kkv FILE will do so. This will tell cvs to treat the
files as text files instead of binary, which is apparently the root of the
problem. (I know, -k is for keywords, but cvs has
Victor Mote [EMAIL PROTECTED] wrote:
[...]
I have never been able to get grep to detect them. The only way I know (and
it falls into the category of beat it to death) is to convert each file
using tr, then compare it to the old one. Here is a script that I just ran
on my box that works:
Jeremias,
The unix 'file' command, with a subsequent check for the work 'text', as
mentioned by Victor earlier, is a very good start for file type checking.
Peter
Jeremias Maerki wrote:
Thanks for your input. Your suggestion below smells dangerous, though.
In the meantime I've started a little
Bertrand Delacretaz wrote:
AFAIK as long as the binary file flag is not set, CVS takes care of line
endings by itself when a file is checked out
(http://www.loria.fr/~molli/cvs/doc/cvs_9.html#SEC76), converting them to
what's appropriate for the platform.
Bertrand,
This needs a bit more
Tim Landscheidt wrote:
Why not just use file(1)?
| [tim@butler ~]$ file /var/tmp/test-{dos,unix}.txt
| /var/tmp/test-dos.txt: ASCII text, with CRLF line terminators
| /var/tmp/test-unix.txt: ASCII text
I thought of that too, but it doesn't work on my Linux box (which reports
both as ASCII
Hi Peter
Yes, file works fine to identify the bad files. It's available on cygwin.
But I think, I'll give my Java-stuff a chance anyway.
On Wed, 06 Nov 2002 12:55:05 +1000 Peter B. West wrote:
The unix 'file' command, with a subsequent check for the work 'text', as
mentioned by Victor
It works on cygwin. Here's some sample output from my Windows machine:
$ file /cygdrive/d/FOP/branch/xml-fop/src/org/apache/fop/apps/*
/cygdrive/d/FOP/branch/xml-fop/src/org/apache/fop/apps/AWTStarter.java: ASCII
C program text, with CRLF line terminators
On Monday 04 November 2002 23:53, Peter B. West wrote:
. . .I don't know the
mechanism for handling line-end differences on entry into a CVS
repository on a unix box.
. . .
AFAIK as long as the binary file flag is not set, CVS takes care of line
endings by itself when a file is checked out
On Monday 04 November 2002 17:02, Jeremias Maerki wrote:
. . .Does anyone have a good idea how to...
2. enforce correct line endings?
Using the commitinfo administrative file, scripts can be configured in CVS to
run when a file is committed, at which point you could detect the problem.
I'm
Thanks, Peter and Betrand, for your answers.
On Tue, 5 Nov 2002 07:21:54 +0100 Bertrand Delacretaz wrote:
On Monday 04 November 2002 17:02, Jeremias Maerki wrote:
. . .Does anyone have a good idea how to...
2. enforce correct line endings?
Using the commitinfo administrative file, scripts
12 matches
Mail list logo
