> From: Lennart Borgman <lennart.borgman.073@...>
> Received: Tue, 11 Oct 2005 09:56:32 AM EDT
> that I had made rather clear that I did not agree, but I did not have =
> Maybe am I misunderstanding "consensus"?
Hmm, well, I looked at an online dictionary which defines it as being
unanimity, solidarity, single opinion. Never in my life have I inteprete=
consensus to mean this. Consensus for me has always implied majority,
minority, difference of opinion, debate, compromise and the willingness t=
disagree (in part or in whole) and commit to action regardless. And if n=
part of any of that, it's fine to go off alone and do it yourself, but ac=
what that also implies. ;-)
> Another reason for not replying promptly was that some of the replies =
> before the voting did have IMHO a smell of flame. I opted to stay out =
> because when flames are in thought is out.
Well for my part, sorry if it got like that. Anyone can get like that fr=
time to time. When flames are in, thought is out, I like that, good word=
remember before posting.
> That is also why I could not =
> take the voting so seriously, but that might have been a mistake. =
Yeah, a mistake. Think of it like this. If people respond so strongly t=
they temporarily lose some rationality, it may be a good indication of ho=
"strange" or "unorthodox" your request is perceived. ;-)
> On one hand I do not want to tolerate =
> flames because they disturb the work and time we offer. On the other =
> hand I did not want to flame back. This is a difficult balance.
Again, good ideas for us all to reflect upon before posting. With this r=
of discussion I think you have walked that fine line well and so I've tri=
respond in like fashion.
> It is a said thing that there tend to be flaming on lists about GPL =
> software. It defeats the purpose I believe most of us have.
Well, it's great that people are passionate about the software. :-) And=
perhaps that energy is best spent in less combustible ways.
> My concern is with files moving between different operating systems. =
> That is of course how the problem we are discussing emerges.
Are you sure? I thought I heard mention of CVS, which raises the issue o=
update contentions with line endings. Does CVS use diffutils? Does CVS =
an option to accept various line endings? I don't know CVS that well at =
But if it's just files being passed around, the issue might still be ther=
But the files should be such a small number that it's little problem to h=
with a conversion utility. If it's many files, should have some version
control, right? ;-)
> I do not =
> care much about right or wrong - the question is rather "what is
In general in life, if a person sees black or white, they miss the infini=
possible other interpretations in the grey area. It's taken many years f=
to appreciate this. But computers know only binary, and for people to
effectively program, they must think in binary (not literally, but the ri=
way or best way is usually a discreetly defined and small set of
possibilities). When we come back to differences of opinion, we may stil=
process in this mode, and may exclude some possibilities or compromises. =
instead it turns into a struggle to define who is right or wrong, and
depending on how much importance that has for defining self worth, may yi=
flamage. I've been there and done that too. :p
> In my opinion diff is mainly for comparing text, not line endings. That=
> is probably what most people use it for.
Well I've checked diffutils home page ( http://gnu.org/software/diffutils=
and it appears to be primarily designed to compare text files. But here =
have some ambiguity. We should clarify. There are three types of
1) Binary (-q or --brief: simple yes or no if they differ)
2) Text (--binary: distinguish between EOL)
3) Text (-a or --text or maybe --strip-trailing-cr: "disregard" EOL)
> The matter we are discussing is from my point of view =
> bigger than "diff in MSYS". To promote portability I would like GNU dif=
> to have the same default
[snip: disregard EOLs :snip]
> should try to avoid making MS Windows the best platform for running GNU=
I do not think that will ever be a problem. :-)
> The reason for raising the question here is that I thought MSYS is a =
> good start and it can be integrated into MS Windows in a good way =
MinGW/MSYS is likely to be one of the few places around that is most
sympathetic to running any GNU/*nixy software in Win32 for the sake of
portability. Yet even here the question you propose is largely resisted.=
This should be considered. Think of the resistance you will receive if y=
try to pose the question to GNU, or to any of the users of software that =
used GNU software (and in particular diff) in native *nixes for 10-20 yea=
(or however long diff existed).
remind yourself, don't think of it as right or wrong. I believe your con=
are valid and have merit. But rather as you say, think of what is useful=
as I say, think of what is realisticly achievable. That is the compromis=
an integral part of consensus. ;-) I think the envvar or conf file migh=
realistically achievable because of much less resistance. Then you can
configure the default behavior, without forcing other people to change th=
opinion about what should be the official, compiled default.
This is one of those common, essential, unspoken, assumed ways of thinkin=
*nix. Nothing will suit everyone, so give me options and I will use them=
Never rely on defaults, but rather define my preferred behavior for a giv=
program with options.
> This are my reasons. I do not know if I have been sufficiently short an=
Likely shorter and clearer than me. :o
> However I would be glad for some convincing reasons why diff =
> should not behave as I have suggested. In what situations is it really =
> useful that diff thinks that files are unequal just because the line =
> ending format are not the same?
Again, this may be "binary" thinking: Either it's the same or it is not, =
tell me. It may just be a good exercise to practice discipline and preci=
when working with computers. Without these things, programmers are likel=
make sloppy work and have a hard time fixing bugs. I'm speaking from
excessive experience. ;-) So regardless of the nature of the diff behav=
the value of forcing the exercise with current defaults far exceeds the
convenience which allows for imprecision.
To paraphrase a movie:
Daniel-san, wax-on, wax-off, stroke up, stroke down, sand left, sand righ=
Now you see the value of these useless exercises?
> I have rewritten this as unit tests, see =
> http://ourcomments.org/Emacs/DL/MSYS/diffutils-2.7/LeifW/. The file =
> TestLeifW contains more information and the tests. (I was reading the =
> message from Leif W when I decided to rewrite my test examples to fit h=
Err, I did not test my test cases, I just invented them and followed the =
format as Earnie's. :p May need tweaking. But also, it's not a complet=
exhaustive test of diff, and currently diff does not seem to respond well=
carriage-return all by itself, or at end of file. More comprehensive tes=
cases might be indicated. The number can get ridiculously high as I thin=
combinations and permutations for discreet test cases.
3 cases for endings with 1 line per file yields: 3 files
compare 2 files at a time yields: 6 tests
3 lines per file (unique line endings) yields: 6 files
compare 2 files at a time yields: 30 tests
What about if we need 5 lines, such that we test the case when a line is =
adjacent to the first or last line. 5 lines per file, 3 unique, 2 repeat=
but which 2? Split again for permutations, or go to 6 lines, to avoid
choosing 2/3, and just double-up? Well, maybe fix (don't change) first a=
last to \n (as \r and \r\n were tested earlier). Comes down to 6 files a=
30 more tests.
66 tests for diff, to be fairly certain about how it might respond in eve=
But that's just line endings. There might be embedded null or non-printa=
characters which make diff treat it differently, no idea what -a might do=
more test cases, more line combinations, more files, much more tests. :p=
Maybe worth it if it yields a mission-critical diff. :-)
Umm, paragraphs? Let's not joke... Ok maybe one paragraph can contain m=
of these combinations, thus reduce the number of files back to a sane lev=
less than 10.
Sorry for verbosity, thinking out loud.