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
/cygdrive/d/FOP/branch/xml-fop/s
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 earlie
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 "A
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 i
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
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 wor
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 ke
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 Nov
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. iden
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, sc
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 n
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
Jeremias,
Never having had the misfortune to work with Windows, I don't know the
mechanism for handling line-end differences on entry into a CVS
repository on a unix box. I assume you have to handle this on your end,
because I occasionally see files with CRLF out of CVS repositories. Is
this
13 matches
Mail list logo
