From: Leif W <war...@us...> - 2005-10-10 14:17:58
|
> From: Lennart Borgman <len...@st...> > Received: Mon, 10 Oct 2005 09:48:06 AM EDT > = > I am looking into the possibility to change and recompile the diffutils= = > that comes with MSYS so that they treat lines on w32 as just lines = > (CR-LF or just LF should not matter by default). This is (as most of yo= u = > surely know by now) the solution that GnuWin32 has choosen. I'm sorry that I can't shed light on the specifics of the source. Howeve= r I do remember that a similar question was posed some months back. Should d= iff's default in windows be to treat RCLF, LF (and CR?) as the same, or as different. I forget the outcome or even if there were any resolutions or= actions taken. Before rehashing that discussion, maybe have a look at th= e list archives, either mingw-msys, mingw-users or mingw-dvlpr, I forget. = Then it may be clearer how best to proceed. Leif |
From: Leif W <war...@us...> - 2005-10-10 18:22:23
|
(condensed, rearranged) >>>>> From: Lennart Borgman <len...@st...> >>>>> Received: Mon, 10 Oct 2005 09:48:06 AM EDT >>>>> >>>>> I am looking into the possibility to change and recompile the = >>>>> diffutils that comes with MSYS so that they treat lines on w32 as = >>>>> just lines (CR-LF or just LF should not matter by default). This is= = >>>>> (as most of you surely know by now) the solution that GnuWin32 has = >>>>> choosen. >>> Greg Chicares wrote: >>> >>> Glancing back at that thread ("Line endings and MSYS diff"), it looks= >>> like this: >>> >>> 4) Treat \n and \r\n as different unless some special switch is >>> applied was the consensus. >> Lennart Borgman wrote: >> = >> My vote was not on that alternative. It creates unnecessary = >> difficulties I believe. > From: Lennart Borgman <len...@st...> > Received: Mon, 10 Oct 2005 01:28:50 PM EDT > > I have made my vote a little bit more concrete now by turning = Heh, funny, you don't like the consensus so you make a "concrete" vote, somehow overrides consensus, or counts as 2+ votes? Everyone can go back= and forth forever here and never agree, so maybe we need to approach another = way? The diff program can do either, with switches. It's a bit silly to recom= pile a different version of a program to get an option to be default. I think= the consensus is "I'd like to know if they're really different, by default." = So I think compiling new static binaries is not a very good solution, but will= just lead to more confusion. You say adding an option (that most don't want to use by default) creates= unneccassary difficulties? I do not recall the specific issues regarding= the build environment. Perhaps you can elaborate (or refer to a thread or example) about why it is not possible to specify arguments to diff your b= uild environment. Similarly, maybe there could be another way to externally set the default= , say an environment variable or config file? Would either of these options be= possible with your build environment? For instance, to test if we're in Windows, and then set a DIFF_EOL (or something) environment variable, and modify diff to check that variable. Or have a system wide diff.conf and per-user .diff config file with the s= ame DIFF_EOL variable name? This way, you can create or modify the file as p= art of configuring the system (in an automated manner), then not have to worr= y which line ending your diff defaults to. Maybe there's an even better way? Leif |
From: Lennart B. <len...@st...> - 2005-10-10 23:14:46
|
Leif W wrote: >(condensed, rearranged) > > >>>>>>From: Lennart Borgman <len...@st...> >>>>>>Received: Mon, 10 Oct 2005 09:48:06 AM EDT >>>>>> >>>>>>I am looking into the possibility to change and recompile the >>>>>>diffutils that comes with MSYS so that they treat lines on w32 as >>>>>>just lines (CR-LF or just LF should not matter by default). This is >>>>>>(as most of you surely know by now) the solution that GnuWin32 has >>>>>>choosen. >>>>>> >>>>>> >>>>Greg Chicares wrote: >>>> >>>>Glancing back at that thread ("Line endings and MSYS diff"), it looks >>>>like this: >>>> >>>> 4) Treat \n and \r\n as different unless some special switch is >>>> applied was the consensus. >>>> >>>> >>>Lennart Borgman wrote: >>> >>>My vote was not on that alternative. It creates unnecessary >>>difficulties I believe. >>> >>> >>From: Lennart Borgman <len...@st...> >>Received: Mon, 10 Oct 2005 01:28:50 PM EDT >> >>I have made my vote a little bit more concrete now by turning >> >> > >Heh, funny, you don't like the consensus so you make a "concrete" vote, >somehow overrides consensus, or counts as 2+ votes? Everyone can go back and >forth forever here and never agree, so maybe we need to approach another way? > > Eh, no, not really ;-) There was no consensus. I did not have time to express my view very clearly at that time, unfortunately. I think a problem was that the change I suggested was believed to break something, but it was unlclear what. One reason for this is perhaps the lacks of tests suite for diff. (At least I can not find any.) I think that our differing views could be more clearly expressed if we nailed down as unit tests. I have therefore made a unit test for this special case and uploaded it to the location I mentioned before. Please feel free to comment on this and add your own view! Fortunately I found when I was doing this that the change I made did not change the input mode to text mode as I thought. It is unclear to me why, but please notice that my changes did not work as I expected! I would appreciate if someone could explain what is happening instead. >The diff program can do either, with switches. It's a bit silly to recompile >a different version of a program to get an option to be default. I think the >consensus is "I'd like to know if they're really different, by default." So I >think compiling new static binaries is not a very good solution, but will just >lead to more confusion. > > Maybe there is something wrong with my test cases then? I suspect that you mean the switch -a? I have two objections to this: is it really used? I have not seen that. It seems to be omitted. Second: I do not really understand what it is doing, see my test cases. >You say adding an option (that most don't want to use by default) creates >unneccassary difficulties? I do not recall the specific issues regarding the >build environment. Perhaps you can elaborate (or refer to a thread or >example) about why it is not possible to specify arguments to diff your build >environment. > > Would you expect that people will start using this switch on both unix:es and MS Windows? I want it to be portable. >Similarly, maybe there could be another way to externally set the default, say >an environment variable or config file? Would either of these options be >possible with your build environment? > > Maybe. But that could indeed introduce errors that are hard to find. I would prefer a standard behaviour and unit tests confirming this. >For instance, to test if we're in Windows, and then set a DIFF_EOL (or >something) environment variable, and modify diff to check that variable. > > Why in Windows? The problem surely exists everywhere. The problem is with files from different operating systems that use different line endings. Not with any particular o/s. |
From: Greg C. <chi...@co...> - 2005-10-11 01:24:19
|
On 2005-10-10 23:14 UTC, Lennart Borgman wrote: > Leif W wrote: > >> (condensed, rearranged) >> >> >>>>>>> From: Lennart Borgman <len...@st...> >>>>>>> Received: Mon, 10 Oct 2005 09:48:06 AM EDT >>>>>>> >>>>>>> I am looking into the possibility to change and recompile the >>>>>>> diffutils that comes with MSYS so that they treat lines on w32 as >>>>>>> just lines (CR-LF or just LF should not matter by default). This >>>>>>> is (as most of you surely know by now) the solution that GnuWin32 >>>>>>> has choosen. >>>>>>> >>>>> >>>>> Greg Chicares wrote: >>>>> >>>>> Glancing back at that thread ("Line endings and MSYS diff"), it looks >>>>> like this: >>>>> >>>>> 4) Treat \n and \r\n as different unless some special switch is >>>>> applied was the consensus. >>>>> >>>> >>>> Lennart Borgman wrote: >>>> >>>> My vote was not on that alternative. It creates unnecessary >>>> difficulties I believe. >>>> >>> >>> From: Lennart Borgman <len...@st...> >>> Received: Mon, 10 Oct 2005 01:28:50 PM EDT >>> >>> I have made my vote a little bit more concrete now by turning >> >> >> Heh, funny, you don't like the consensus so you make a "concrete" vote, >> somehow overrides consensus, or counts as 2+ votes? Everyone can go >> back and >> forth forever here and never agree, so maybe we need to approach >> another way? >> >> > Eh, no, not really ;-) > > There was no consensus. I disagree. Let's examine the facts. Here's how I count the responses to Earnie's question [1] (let me know if I haven't fairly represented anyone's POV): On 2005-8-5 15:06 UTC, Max T. Woodbury wrote: dislikes 2 and 5 On 2005-8-5 15:25 UTC, Larry Berlinski wrote: likes 4 and 6 On 2005-8-5 15:35 UTC, Greg Chicares wrote: likes 1; OK with 4; dislikes 2 and 3 On 2005-8-5 16:30 UTC, Leif W wrote: likes 1 or 4; OK with 6 On 2005-8-5 17:05 UTC, Duncan Murdoch wrote: suggests 1 or 4 On 2005-8-5 19:59 UTC, Tuomo Latto wrote: prefers 3 or 4 [but would probably like 3 better, I think] On 2005-8-5 21:44 UTC, John Vandenberg wrote: likes 1; OK with 4; dislikes 2, 3, and 5, and perhaps 6 On 2005-8-7 15:39 UTC, Ross Ridge wrote: I think this is a vote for 3 On 2005-8-7 16:45 UTC, Egon Andersen wrote: prefers 4 On 2005-8-7 17:07 UTC, Igor Mikolic-Torreira wrote: prefers 4 Of the ten respondents, eight are at least OK with #4, and four with #1. No other option was spoken of favorably by more than two. How can you say there wasn't consensus for #4? > I did not have time to express my view very > clearly at that time, unfortunately. I think a problem was that the > change I suggested was believed to break something, but it was unlclear > what. One reason for this is perhaps the lacks of tests suite for diff. > (At least I can not find any.) I think that our differing views could be > more clearly expressed if we nailed down as unit tests. I have therefore > made a unit test for this special case and uploaded it to the location I > mentioned before. What's lacking in Earnie's original testcase [1]? After rereading the August messages, I think the issues were carefully considered. Why not look back on that and consider proposing a change the community would support--or give a brief, convincing reason why most of us were wrong? --------- [1] Earnie's original message: On 2005-8-5 14:15 UTC, Earnie Boyd wrote: > Subject: Line endings and diff > > <file name="foo1.txt"> > foo\n > </file> > > <file name="foo2.txt"> > foo\r\n > </file> > > <command action="diff -u foo1.txt foo2.txt"> > <result> > --- foo1.txt Fri Aug 5 09:43:49 2005 > +++ foo2.txt Fri Aug 5 09:44:17 2005 > @@ -1 +1 @@ > -foo\n > +foo\r\n > </result> > </command> > > I've set up the above example to discuss what the Community would wish MSYS > diff to do in the above. Current MSYS diff executes as seen above and thus > works the same as if you were to execute the command on a UNIX OS. Others > have asked that \r\n be treated equivalent to \n even though in reality the > files are different. > > Options for change: > 1) No change. > 2) Treat \n and \r\n the same regardless** ***. > 3) Treat \n and \r\n the same unless some special switch is applied** ***. > 4) Treat \n and \r\n as different unless some special switch is applied* ** > ***. > 5) Supply a native version of diff instead of the MSYS diff***. > 6) Supply a native version of diff renamed to mingw32-diff***. > > * Current MSYS diff -w or -b will treat \r as white space but if you want > white space differences then this doesn't work well. > > ** If these changes are accomplished the output line endings would still > retain the line ending in the respective file if other differences are > found. Modifcations to patch may also need to happen. > > *** There is danger of introducing \r\n when the files do not contain them > originally if patch is used to apply the difference elsewhere. > > The people having the most problems are those using native tools that spawn > MSYS processes. Another place where the current MSYS diff presents a > problem is when doing the unit tests when a comparison file is used to find > a regression (such as is used by GNU make). > > So, I'm looking for ideas and suggestions. |
From: Lennart B. <len...@st...> - 2005-10-11 13:55:33
|
Greg Chicares wrote: >Here's how I count the responses to Earnie's question [1] >(let me know if I haven't fairly represented anyone's POV): > > On 2005-8-5 15:06 UTC, Max T. Woodbury wrote: > dislikes 2 and 5 > > On 2005-8-5 15:25 UTC, Larry Berlinski wrote: > likes 4 and 6 > > On 2005-8-5 15:35 UTC, Greg Chicares wrote: > likes 1; OK with 4; dislikes 2 and 3 > > On 2005-8-5 16:30 UTC, Leif W wrote: > likes 1 or 4; OK with 6 > > On 2005-8-5 17:05 UTC, Duncan Murdoch wrote: > suggests 1 or 4 > > On 2005-8-5 19:59 UTC, Tuomo Latto wrote: > prefers 3 or 4 [but would probably like 3 better, I think] > > On 2005-8-5 21:44 UTC, John Vandenberg wrote: > likes 1; OK with 4; dislikes 2, 3, and 5, and perhaps 6 > > On 2005-8-7 15:39 UTC, Ross Ridge wrote: > I think this is a vote for 3 > > On 2005-8-7 16:45 UTC, Egon Andersen wrote: > prefers 4 > > On 2005-8-7 17:07 UTC, Igor Mikolic-Torreira wrote: > prefers 4 > >Of the ten respondents, eight are at least OK with #4, and four with #1. >No other option was spoken of favorably by more than two. How can you >say there wasn't consensus for #4? > > Thanks for collecting this. As I just said in another mail I thought that I had made rather clear that I did not agree, but I did not have time to elaborate on it at that time. Maybe am I misunderstanding "consensus"? 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. That is also why I could not take the voting so seriously, but that might have been a mistake. However after some hard words I know there are people that prefer to "shut up" to avoid the annoyances of flames. I took some time to write a page about this I was not satisfied with the tone on the page so I did not publish is officially yet. 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. 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. >What's lacking in Earnie's original testcase [1]? After rereading the >August messages, I think the issues were carefully considered. Why not >look back on that and consider proposing a change the community would >support--or give a brief, convincing reason why most of us were wrong? > > Yes, you are right. Seems like I should have gone back reading again before posting. Sorry. My concern is with files moving between different operating systems. That is of course how the problem we are discussing emerges. I do not care much about right or wrong - the question is rather "what is useful". In my opinion diff is mainly for comparing text, not line endings. That is probably what most people use it for. I am not sure of this of course. My interest in diff comes from using Emacs. In Emacs I tend to edit files and compare files that may have different line endings. In Emacs there is a very useful tool called ediff for comparing and merging files. This tool depends on diff and if diff compares line endings then ediff is rendered totally useless when the files have different line endings. Converting the files is tedious and not a very good option since I may have got them from a CVS repository for example. There are other tools for doing the same thing as ediff in Emacs. WinMerge is such a tool. It seems very good to me. I lack some of the capabilities in Emacs, but on the other hand WinMerge is more simple to use if you do not know Emacs -- and it does not depend on external tools. How then does WinMerge handle line endings? The default (I believe at the moment, I might have changed it ;-) is to "Ignore carrigage return differences (DOS/UNIX/MAC)" as they call it. It guess they have choosen this because it is useful. Using WinMerge is however a lockin to MS Windows. I would be glad if we could avoid that. The matter we are discussing is from my point of view bigger than "diff in MSYS". To promote portability I would like GNU diff to have the same default as I above thought that WinMerge has. I have nothing against switches, but the default behaviour should IMHO be this - on all platforms where GNU diff exists. (I agree with RMS that we should try to avoid making MS Windows the best platform for running GNU software.) 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 (though there is a way to go). As you may have noticed I have also tried to see if GnuWin32 could be used instead for my special purpose of making Emacs easily useful on MS Windows. It can to a certain degree, but you need a sh too and that is where MSYS comes in. Porting bash (that much it could) however takes more time and knowledge than I am able to bring into this for now. This are my reasons. I do not know if I have been sufficiently short and clear. 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? Could such situations be handled with diff+cmp? Are there any old scripts that rely on the current GNU diff behaviour? (Examples, please.) >--------- > >[1] Earnie's original message: > >On 2005-8-5 14:15 UTC, Earnie Boyd wrote: > > >>Subject: Line endings and diff >> >><file name="foo1.txt"> >>foo\n >></file> >> >><file name="foo2.txt"> >>foo\r\n >></file> >> >> 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 his.) Kind regards, Lennart |
From: Leif W <war...@us...> - 2005-10-10 23:52:36
|
> From: Lennart Borgman <len...@st...> > Received: Mon, 10 Oct 2005 07:15:19 PM EDT > = > (At least I can not find any.) I think that our differing views could b= e = > more clearly expressed if we nailed down as unit tests. I have therefor= e = > made a unit test for this special case and uploaded it to the location = I = > mentioned before. Please feel free to comment on this and add your own view! Sorry, misunderstood that! Of course, I'll go and play with anything the= re, as soon as I have enough time. :-) > Maybe there is something wrong with my test cases then? I did not look yet, sorry. :-) > I suspect that you mean the switch -a? I have two objections to this: i= s = > it really used? I have not seen that. It seems to be omitted. Second: I= = > do not really understand what it is doing, see my test cases. I've used -a / --text in Linux (and other nix) for years and in msys for = a while, but not thorughly tested... Usually I need to know if there's ext= ra spaces, sometimes it breaks things, mostly I'm diffing small binary files= anyways, and sometimes I don't know what line endings were used, but need= to quickly determine differences, but usually I check it binary and convert = line endings if needed. As to what -a does, I have no idea, it's just worked for me. But I could= endeavor to look at the source, but may not understand quickly. ;-) As = for test cases, I could try them, maybe better understand what you mean by al= l this. > Would you expect that people will start using this switch on both = > unix:es and MS Windows? I want it to be portable. As I said, for years the -a flag has been there in *nix worlds. > Maybe. But that could indeed introduce errors that are hard to find. I = > would prefer a standard behaviour and unit tests confirming this. Well, yes, but very simple programs with very simple options should be of= much less concern when other more complicated things can break. ;-) But even= so, as I said, it's a last resort. > Why in Windows? The problem surely exists everywhere. The problem is = > with files from different operating systems that use different line = > endings. Not with any particular o/s. Well, I just meant an example of one case. Test in every OS, and for tha= t OS set the default line endings in some variable. I am talking about a gene= ric solution. But these are the last ideas on my list. The first is always to use bina= ry by default, and -a for text. ;-) diff is a nix program, and the default is= binary there. Change the default in win, then there's maybe compatibilit= y problems? If it's misconception or fact, I don't know, I'll definitely l= ook carefully at test cases you've made. Leif |
From: Keith M. <kei...@to...> - 2005-10-11 08:44:54
|
[Greg Chicares] > Glancing back at that thread ("Line endings and MSYS diff"), it looks > like this: > > 4) Treat \n and \r\n as different unless some special switch is > applied was the consensus. [Lennart Borgman] > My vote was not on that alternative. It creates unnecessary > difficulties I believe. > I have made my vote a little bit more concrete now by turning [Leif W] > Heh, funny, you don't like the consensus so you make a "concrete" vote, > somehow overrides consensus, or counts as 2+ votes? Everyone can go back and > forth forever here and never agree, so maybe we need to approach another way? [Lennart Borgman] > Eh, no, not really ;-) > > There was no consensus. [...] Eh? I didn't vote at the time, because I was on holiday. I reviewed the thread on my return, saw that there WAS a CLEAR concensus -- it was as Greg has stated above. That was a consensus with which I was more than happy, and given that it was reached before I became involved, I didn't add my 2d. FWIW, I do so now: PLEASE DO NOT BREAK DIFF, by making it behave in any default manner other than it currently exhibits. So, why should diff treat CRLF == CR == LF? It most definitely SHOULD NOT. If you compare two files, with CRLF vs. LF differences only, on a GNU/Linux system they will compare as different, because they ARE different, and that is just how it should be. If that causes you grief, then you are not managing your files adequately; use dos2unix or unix2dos, to make all your files obey consistent line ending rules; smack the misbehaving files, NOT the tool which is behaving as it should -- dare I say it? "A bad workman always blames his tools". If any change is to be made to diff, then it should be in accord with the consensus, i.e. add a custom option, turned OFF by default, which activates the CRLF == CR == LF comparison mode, perhaps adopting any of the envvar or config file techniques, suggested by Leif W, to establish a local default; submit a patch for consideration, and see how it is received. If you still don't like the result, then feel free to keep your patched version for private use, or use the GnuWin32 implementation you seem to favour -- that is the way of free software; you have to freedom to make it work for you, in the way you want it to. Continued whingeing here will serve only to make you deeply unpopular. Regards, Keith. |
From: Lennart B. <len...@st...> - 2005-10-11 14:10:12
|
Keith MARSHALL wrote: >happy, and given that it was reached before I became involved, I didn't >add my 2d. FWIW, I do so now: PLEASE DO NOT BREAK DIFF, by making it >behave in any default manner other than it currently exhibits. > > The only way to not break it is perhaps to have some tests that defines its behaviour? On w32 we currently have several different behaviours of diff. >If any change is to be made to diff, then it should be in accord with >the consensus, i.e. add a custom option, turned OFF by default, which >activates the CRLF == CR == LF comparison mode, perhaps adopting any of >the envvar or config file techniques, suggested by Leif W, to establish >a local default; submit a patch for consideration, and see how it is >received. > I will submit a patch. The problem is I am much less than an expert on the internals. I am after the tools behaviour and robustness. >Continued whingeing here will serve only to make you deeply unpopular. > > Thank you for learning me a new word, I had to look it up ;-) More seriously, I am trying to get things working, not breaking them. If you do not hear this from others it might have been that they have given up. I tend to have more trust in that you all here want to help, but that the tone sometimes mistakingly is unhelpful. I am sorry if I also have been harsh. |
From: Lennart B. <len...@st...> - 2005-10-11 23:35:08
Attachments:
cvs-diff-u.tmp
|
Keith MARSHALL wrote: >submit a patch for consideration, and see how it is >received. > I have tried to patch the current MSYS CVS version of packages/diffutils. This version works for the default (reading data as text) but fails for --binary for some reason. I am still sending it now so you can consider it. I think I am mainly turning on features that are supposed to be available on MS Windows (see my message with the excerpt from the GNU diff manual). I have attached the "cvs diff -u" output. I also tried the latest DiffUtils from gnu.org. When running configure under uname MSYS_NT-5.0 I got the following error: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checking build system type... config/config.guess: unable to guess system type This script, last modified 2002-03-20, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from ftp://ftp.gnu.org/pub/gnu/config/ If the version you run (config/config.guess) is already up to date, please send the following data and any information you think might be pertinent to <con...@gn...> in order to provide the needed information to handle your system. config.guess timestamp = 2002-03-20 uname -m = i686 uname -r = 1.0.10(0.46/3/2) uname -s = MSYS_NT-5.0 uname -v = 2004-03-15 07:17 /usr/bin/uname -p = unknown /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = i686 UNAME_RELEASE = 1.0.10(0.46/3/2) UNAME_SYSTEM = MSYS_NT-5.0 UNAME_VERSION = 2004-03-15 07:17 configure: error: cannot guess build type; you must specify one <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Should we send this to gnu.org to get MSYS into configure.guess? Is this maybe already done? I do not know what more should be provided to them in order to get this working? Kind regards, Lennart |
From: Earnie B. <ea...@pr...> - 2005-10-12 23:33:22
|
Quoting Lennart Borgman <len...@st...>: > config.guess timestamp = 2002-03-20 > > uname -m = i686 > uname -r = 1.0.10(0.46/3/2) > uname -s = MSYS_NT-5.0 > uname -v = 2004-03-15 07:17 > > /usr/bin/uname -p = unknown > /bin/uname -X = > > hostinfo = > /bin/universe = > /usr/bin/arch -k = > /bin/arch = > /usr/bin/oslevel = > /usr/convex/getsysinfo = > > UNAME_MACHINE = i686 > UNAME_RELEASE = 1.0.10(0.46/3/2) > UNAME_SYSTEM = MSYS_NT-5.0 > UNAME_VERSION = 2004-03-15 07:17 > configure: error: cannot guess build type; you must specify one > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > FYI, O_TEXT using the MSYS runtime is meaningless as MSYS forces binary mode I/O regardless. There are reasons I decided to do this that I don't have time to explain now. > Should we send this to gnu.org to get MSYS into configure.guess? Is > this maybe already done? > No, and no again. I've asked the maintainer of config.guess and config.sub to not accept such patches as the MSYS target is a private case. > I do not know what more should be provided to them in order to get > this working? > Unless you read the end of the line and handle the line ending to make them match you won't get it to work as an MSYS application. I purposely made them work as it would on a POSIX system since MSYS is emulating a POSIX environment. The best method to handle this is as Keith has suggested. If the files have different line endings then make them have the same line endings before executing diff. That process has been used since DOS was created and we started passing files back and forth. Earnie |
From: Lennart B. <len...@st...> - 2005-10-13 06:48:19
|
Earnie Boyd wrote: > FYI, O_TEXT using the MSYS runtime is meaningless as MSYS forces > binary mode I/O > regardless. There are reasons I decided to do this that I don't have > time to > explain now. I think I understand it by reading your answer below (though not the details, but that does not matter now). > >> Should we send this to gnu.org to get MSYS into configure.guess? Is >> this maybe already done? >> > > No, and no again. I've asked the maintainer of config.guess and > config.sub to > not accept such patches as the MSYS target is a private case. Ok, thanks. > Unless you read the end of the line and handle the line ending to make > them > match you won't get it to work as an MSYS application. I purposely > made them > work as it would on a POSIX system since MSYS is emulating a POSIX > environment. I see. This mean that I am reading the wrong part of the GNU diff manual for the MSYS diff. MSYS diff is in a sense not running "in operating systems that distinguish between text and binary files". I think it should be pointed out very clearly that this is the case in the manual (and that this applies to all programs in MSYS bin directory). I can see you have a good reason for this handling of the line endings, but for me and many others this does not work well all the time. So I am very interested in the answer to the question about using GnuWin32 tools together with MSYS sh that I made in another message. > > The best method to handle this is as Keith has suggested. If the > files have > different line endings then make them have the same line endings before > executing diff. That process has been used since DOS was created and we > started passing files back and forth. There are different opinions on this. That you do not hear other opinions here is maybe because those that disagree are using the GnuWin32 tool chain instead. I see nothing wrong with this, but I wonder about coexistence (see above). Kind regards, Lennart |
From: Earnie B. <ea...@pr...> - 2005-10-12 23:36:12
|
Quoting Lennart Borgman <len...@st...>: > > UNAME_MACHINE = i686 > UNAME_RELEASE = 1.0.10(0.46/3/2) > UNAME_SYSTEM = MSYS_NT-5.0 > UNAME_VERSION = 2004-03-15 07:17 > configure: error: cannot guess build type; you must specify one > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > Copy the config.guess and config.sub from the msysDVLPR package replacing these. Earnie |
From: Lennart B. <len...@st...> - 2005-10-13 06:30:45
|
Earnie Boyd wrote: > Quoting Lennart Borgman <len...@st...>: > > >> >> UNAME_MACHINE = i686 >> UNAME_RELEASE = 1.0.10(0.46/3/2) >> UNAME_SYSTEM = MSYS_NT-5.0 >> UNAME_VERSION = 2004-03-15 07:17 >> configure: error: cannot guess build type; you must specify one >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> > > Copy the config.guess and config.sub from the msysDVLPR package > replacing these. Thanks, but there are several different of different size. Which one do you mean? D:\mingwcvs>dir /s /b config.guess D:\mingwcvs\bash-test\bash\2.04\support\config.guess D:\mingwcvs\bash-test\bash\2.05b\support\config.guess D:\mingwcvs\msys\packages\bash\2.04\support\config.guess D:\mingwcvs\msys\packages\bash\2.05b\support\config.guess D:\mingwcvs\msys\packages\diffut-gnuwin32\config\config.guess D:\mingwcvs\msys\packages\fileutils\4.1\config.guess D:\mingwcvs\msys\packages\gawk\3.0.4\config.guess D:\mingwcvs\msys\packages\grep\2.4.2\config.guess D:\mingwcvs\msys\packages\make\3.79.1\config.guess D:\mingwcvs\msys\packages\rxvt\2.7.9\autoconf\config.guess D:\mingwcvs\msys\packages\sh-utils\2.0\config.guess D:\mingwcvs\msys\packages\texinfo\4.0\config.guess D:\mingwcvs\msys\packages\texinfo\4.3\config.guess D:\mingwcvs\msys\packages\textutils\2.0\config.guess D:\mingwcvs\msys\rt\src\config.guess D:\msys>dir /s /b config.guess D:\msys\1.0\share\automake-1.7\config.guess D:\msys\1.0\share\libtool\config.guess |
From: Earnie B. <ea...@pr...> - 2005-10-13 12:10:50
|
Quoting Lennart Borgman <len...@st...>: > Earnie Boyd wrote: > >> Quoting Lennart Borgman <len...@st...>: >> >> >>> >>> UNAME_MACHINE = i686 >>> UNAME_RELEASE = 1.0.10(0.46/3/2) >>> UNAME_SYSTEM = MSYS_NT-5.0 >>> UNAME_VERSION = 2004-03-15 07:17 >>> configure: error: cannot guess build type; you must specify one >>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >>> >> >> Copy the config.guess and config.sub from the msysDVLPR package >> replacing these. > > > Thanks, but there are several different of different size. Which one > do you mean? > It doesn't matter as long as ``grep -i msys config.guess'' returns strings. Earnie |
From: Leif W <war...@us...> - 2005-10-11 10:29:09
|
> From: Greg Chicares <chi...@co...> > Received: Mon, 10 Oct 2005 09:25:35 PM EDT > Here's how I count the responses to Earnie's question [1] Wow, thanks for the vote count. > What's lacking in Earnie's original testcase [1]? Well, for devil's advocacy, file with CR line ending and tests. See belo= w. I generated the files by hand and verified the result on a Linux box. I fabircated time stamps to make it look similar. I wonder if there's issu= es with multi-line files with different endings, maybe test for that too. H= mm, yes, glad I did test, the result is 'interesting'. Maybe a bug in my Lin= ux diff? (not in Win at the moment). > [1] Earnie's original message: > = > On 2005-8-5 14:15 UTC, Earnie Boyd wrote: > > Subject: Line endings and diff > > > > <file name=3D"foo1.txt"> > > foo\n > > </file> > > > > <file name=3D"foo2.txt"> > > foo\r\n > > </file> <file name=3D"foo3.txt"> foo\r </file> <file name=3D"foo4.txt"> foo\n foo\r\n foo\r </file> <file name=3D"foo5.txt"> foo\r foo\n foo\r\n </file> > > <command action=3D"diff -u foo1.txt foo2.txt"> > > <result> > > --- foo1.txt Fri Aug 5 09:43:49 2005 > > +++ foo2.txt Fri Aug 5 09:44:17 2005 > > @@ -1 +1 @@ > > -foo\n > > +foo\r\n > > </result> > > </command> <command action=3D"diff -u foo1.txt foo3.txt"> <result> --- foo1.txt Fri Aug 5 09:43:49 2005 +++ foo3.txt Fri Aug 5 09:45:35 2005 @@ -1 +1 @@ -foo\n +foo\r \ No newline at end of file </result> </command> <command action=3D"diff -u foo2.txt foo3.txt"> <result> --- foo2.txt Fri Aug 5 09:43:49 2005 +++ foo3.txt Fri Aug 5 09:45:35 2005 @@ -1 +1 @@ -foo\r\n +foo\r \ No newline at end of file </result> </command> <command action=3D"diff -u foo4.txt foo5.txt" <result> --- foo4.txt Fri Aug 5 09:47:22 2005 +++ foo5.txt Fri Aug 5 09:47:44 2005 @@ -1,3 +1,2 @@ -foo fooo foo -foo \ No newline at end of file </result> </command> When confronted with foo4.txt and foo5.txt in the wild, you've got real problems. :-) How best to handle? Have to treat the entire file as a string, match \r\n, \n, \r and replace with desired line ending. Note th= at you want to match and replace the \r\n sequence first. Leif |
From: Keith M. <kei...@to...> - 2005-10-11 14:53:45
|
Lennart Borgman wrote, quoting me: >> ... PLEASE DO NOT BREAK DIFF, by making it >> behave in any default manner other than it currently exhibits. > > The only way to not break it is perhaps to have some tests that > defines its behaviour? On w32 we currently have several different > behaviours of diff. And those that treat different line ending protocols as identical, by default, are IMHO, broken. The definitively "correct" behaviour is that which most closely conforms to that of the same tool on it's native platform, i.e. a genuine POSIX or UNIX system. Run Earnie's two test files through diff on GNU/Linux, or on Solaris, or probably any other UNIX, and they will compare as DIFFERENT. IMO, any diff which says otherwise, UNLESS invoked with some special switch to modify its behaviour, is just plain WRONG. Regards, Keith. |
From: Lennart B. <len...@st...> - 2005-10-11 21:11:52
|
Keith MARSHALL wrote: >Lennart Borgman wrote, quoting me: > > >>>... PLEASE DO NOT BREAK DIFF, by making it >>>behave in any default manner other than it currently exhibits. >>> >>> >>The only way to not break it is perhaps to have some tests that >>defines its behaviour? On w32 we currently have several different >>behaviours of diff. >> >> > >And those that treat different line ending protocols as identical, >by default, are IMHO, broken. > >The definitively "correct" behaviour is that which most closely >conforms to that of the same tool on it's native platform, i.e. a >genuine POSIX or UNIX system. Run Earnie's two test files through >diff on GNU/Linux, or on Solaris, or probably any other UNIX, and >they will compare as DIFFERENT. IMO, any diff which says otherwise, >UNLESS invoked with some special switch to modify its behaviour, >is just plain WRONG. > > Running the tests on different platform is a good idea. Doing that in the form of the unit tests I uploaded might be useful for collecting results. The output from these tests also contains uname -a and diff --version to make this easier. I feel a bit like a parrot, but portability is my main issue. Whether diff should have a special switch for the case we are discussing is for me of second importance. However I have tried to understand what the current situation actually is. Reading the Posix spec does not throw much light on our current problem. The Posix documentation simply says that a line ends in <newline>. This is \n in C which is just C-j. This definition unfortunately does not include w32 line endings. Then it can not be of any importance here. Reading the GNU diff manual is more interesting. It says the following: "In operating systems that distinguish between text and binary files, |diff| normally reads and writes all data as text. Use the |--binary| option to force |diff| to read and write binary data instead. This option has no effect on a POSIX-compliant system like GNU or traditional Unix. " As far as I can see this could be read to mean that the GnuWin32 behaviour of GNU diff is the correct since it actually reads the data as text. It also provides the --binary option. Can you read this in another way? (This is not meant as an insult, I am actually not sure -- yet.) So you might think that I am pleased with this ;-) -- actually not completely, because this solution is not completely portable. A switch like --any-line-ends that worked on all platform would IMHO be good. I raise this issue here because I feel that we on this list are concerned about portability issues and that we feel that moving to GNU/Linux is desirable in the long run. That is at least why I am here. Kind regards, Lennart |
From: Keith M. <kei...@to...> - 2005-10-12 09:36:09
|
Lennart Borgman wrote: > configure: error: cannot guess build type; you must specify one > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Should we send this to gnu.org to get MSYS into configure.guess? > Is this maybe already done? I'll defer to Earnie on this; I know he is not keen to have the autotools explicitly identify MSYS, (as opposed to MINGW), as a publicly supported build system, but maybe config.guess should be an exception. If not, the MSYS sources should include a locally patched config.guess, (so that _they_ at least recognise their own native build environment); you should be able to drop this into the generic GNU source tree, to work around this problem. > I have tried to patch the current MSYS CVS version of > packages/diffutils. [...] > I have attached the "cvs diff -u" output. Without having studied the original code, here are some initial comments on your patch:-- 1) It will never be accepted, if you don't accompany it with an appropriately formatted ChangeLog entry. 2) All you appear to have done is unconditionally force diff to use text mode for *all* I/O streams. This is diametrically opposed the the general consensus of opinion that the default behaviour of diff should remain unchanged. > diff -u -r1.1.1.1 system.h > --- 2.7/system.h 5 May 2002 17:03:08 -0000 1.1.1.1 > +++ 2.7/system.h 11 Oct 2005 23:22:33 -0000 > @@ -236,9 +236,12 @@ > #endif > > #ifndef HAVE_SETMODE > -#define HAVE_SETMODE 0 > +//#define HAVE_SETMODE 0 > #endif > > +/* I believe this should be set -LB */ > +#define HAVE_SETMODE 1 3) No, it shouldn't. This defeats the purpose of configuring the package. What should happen is that configure should check for setmode, using `AC_CHECK_FUNCS([setmode])', thus adding the `#define HAVE_SETMODE 1' to config.h, but only when it is pertinent. The purpose of this fragment in system.h is to ensure that, on systems where setmode isn't available, that `#if HAVE_SETMODE' works properly. If configure isn't doing this, then you should either specify `-DHAVE_SETMODE=1' within CFLAGS, (on your configure command line), or better, patch configure.ac to add the appropriate test, and rerun autoconf and autoheader before you start. > diff -u -r1.1.1.1 diff.c > --- 2.7/diff.c 5 May 2002 17:03:02 -0000 1.1.1.1 > +++ 2.7/diff.c 11 Oct 2005 23:22:32 -0000 > @@ -555,8 +555,10 @@ > /* Use binary I/O when reading and writing data. > On Posix hosts, this has no effect. */ > #if HAVE_SETMODE > - binary_I_O = 1; > - setmode (STDOUT_FILENO, O_BINARY); > + //binary_I_O = 1; > + binary_I_O = 0; > + //setmode (STDOUT_FILENO, O_BINARY); > + setmode (STDOUT_FILENO, O_TEXT); > #endif 4) Only if this appears within the scope of the processing of a new command line option, (which you haven't provided), which explicitly activates the Win32 CRLF == LF operating mode. > @@ -1064,6 +1066,10 @@ > for (i = 0; i <= 1; i++) > if (0 <= inf[i].desc) > setmode (inf[i].desc, O_BINARY); > + if (!binary_I_O) > + for (i = 0; i <= 1; i++) > + if (0 <= inf[i].desc) > + setmode (inf[i].desc, O_TEXT); 5) The second `for' loop is redundant here; just write the first as: for (i = 0; i <= 1; i++) if (0 <= inf[i].desc) setmode (inf[i].desc, binary_I_O ? O_BINARY : O_TEXT); > This version works for the default (reading data as text) but fails > for --binary for some reason. Perhaps because your patch precludes the possibility of `binary_I_O' ever being set to one; (just a guess, at present). Regards, Keith. |
From: Lennart B. <len...@st...> - 2005-10-12 12:45:27
|
Keith MARSHALL wrote: >I'll defer to Earnie on this; I know he is not keen to have the >autotools explicitly identify MSYS, (as opposed to MINGW), as a >publicly supported build system, but maybe config.guess should be >an exception. If not, the MSYS sources should include a locally >patched config.guess, (so that _they_ at least recognise their own >native build environment); you should be able to drop this into >the generic GNU source tree, to work around this problem. > > Thanks, it makes me curious, I wonder what Earnie have against it. The current solution makes it a bit difficult to compile newer versions of for example Diffutils. I looked in MSYS packages/diffutils but I could not find any configure.guess. What is the reason for this? Is it somewhere else? >Without having studied the original code, here are some initial >comments on your patch:-- > >1) It will never be accepted, if you don't accompany it with an > appropriately formatted ChangeLog entry. > > I keep that in my head, but this patch was just for comments. >2) All you appear to have done is unconditionally force diff to > use text mode for *all* I/O streams. This is diametrically > opposed the the general consensus of opinion that the default > behaviour of diff should remain unchanged. > > That is just a mistake, I did not want to force diff to use text mode for cases. In this patch I tried to follow the GNU diff manual (but maybe there is some bug in this version of Diffutils?). I know this is not what was seen by you and several others consensus. (I just looked up the word "consensus". Does not that mean that all participants should agree?) I think it makes sense still because we where probably not aware of that part of the GNU diff manual that I quoted in an earlier message before. >>+/* I believe this should be set -LB */ >>+#define HAVE_SETMODE 1 >> >> > >3) No, it shouldn't. This defeats the purpose of configuring the > package. What should happen is that configure should check for > setmode, using `AC_CHECK_FUNCS([setmode])', thus adding the > `#define HAVE_SETMODE 1' to config.h, but only when it is > pertinent. The purpose of this fragment in system.h is to > ensure that, on systems where setmode isn't available, that > `#if HAVE_SETMODE' works properly. > > Yes, thanks, of course. I just meant that the configure process should have set it. Some afterthought: Could the problem that this was left has it roots in that MSYS truly tries to be a "GNU environment" on w32 that looks very much like the environment on GNU/Linux? Could it just be that some fine tuning should be made because of the fact that the underlying system in fact is w32? > If configure isn't doing this, then you should either specify > `-DHAVE_SETMODE=1' within CFLAGS, (on your configure command > line), or better, patch configure.ac to add the appropriate > test, and rerun autoconf and autoheader before you start. > > I do not understand the organisation of things here. (And I do not know configure.ac but that is not the trouble at the moment ;-) I can not find any configure.ac in MSYS packages/diffutils. Is this some older version of the configure scripts? >5) The second `for' loop is redundant here; just write the first > as: > > for (i = 0; i <= 1; i++) > if (0 <= inf[i].desc) > setmode (inf[i].desc, binary_I_O ? O_BINARY : O_TEXT); > > Thanks, just my stupidity when I was in a hurry compiling. > > >>This version works for the default (reading data as text) but fails >>for --binary for some reason. >> >> > >Perhaps because your patch precludes the possibility of `binary_I_O' >ever being set to one; (just a guess, at present). > > Probably, I will fix that. Thanks, Lennart |
From: Earnie B. <ea...@pr...> - 2005-10-12 23:45:50
|
Quoting Lennart Borgman <len...@st...>: > Thanks, it makes me curious, I wonder what Earnie have against it. > The current solution makes it a bit difficult to compile newer > versions of for example Diffutils. > > I looked in MSYS packages/diffutils but I could not find any > configure.guess. What is the reason for this? Is it somewhere else? > I don't know where the config.guess and config.sub have gone. I certainly didn't mean to leave it out. Copy the config.guess and config.sub from msysDVLPR package into the top source directory. Earnie |
From: Keith M. <kei...@to...> - 2005-10-12 11:28:51
|
Lennart Borgman wrote: > Running the tests on different platform is a good idea. Doing > that in the form of the unit tests I uploaded might be useful > for collecting results. Your tests aren't sufficiently portable, to let that happen on any non-GNU flavour of UNIX. > The output from these tests also contains uname -a and > diff --version to make this easier. `uname -a' is ok, (should be ubiquitous), but `diff --version' will choke with an "illegal option" exception, if I try to run it on SunOS/Solaris; similarly `diff -u' is not universally supported, (and will also choke on SunOS/Solaris). `diff -c' is more portable, (SunOS/Solaris *does* support it), but for ultimate portability you need to run a bare diff command *without* options. You should also be aware that the shUnit test framework you have employed will, itself, crash the standard shell on many current (and older) BSD systems; (this is because the ${varname:-value} construct is not permitted -- only ${varname-value} is allowed). Regards, Keith. |
From: Lennart B. <len...@st...> - 2005-10-12 12:53:14
|
Keith MARSHALL wrote: >Your tests aren't sufficiently portable, to let that happen on >any non-GNU flavour of UNIX. >... > > >>The output from these tests also contains uname -a and >>diff --version to make this easier. >> >> > >`uname -a' is ok, (should be ubiquitous), but `diff --version' >will choke with an "illegal option" exception, if I try to run >it on SunOS/Solaris; similarly `diff -u' is not universally >supported, (and will also choke on SunOS/Solaris). `diff -c' >is more portable, (SunOS/Solaris *does* support it), but for >ultimate portability you need to run a bare diff command >*without* options. > > Would "diff --version 2>&1 || echo Not GNU diff, unknown version" be a useful solution? >You should also be aware that the shUnit test framework you have >employed will, itself, crash the standard shell on many current >(and older) BSD systems; (this is because the ${varname:-value} >construct is not permitted -- only ${varname-value} is allowed). > > That is a pitty. I do not want to change this myself but can try to carry it back to the maintainers. However I believe there main target is Posix compliant systems. (And I should not change it because I do not know this stuff that well!) Kind regards, Lennart |
From: Leif W <war...@us...> - 2005-10-12 13:25:03
|
> From: Lennart Borgman <len...@st...> > 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= d consensus to mean this. Consensus for me has always implied majority, minority, difference of opinion, debate, compromise and the willingness t= o disagree (in part or in whole) and commit to action regardless. And if n= ot part of any of that, it's fine to go off alone and do it yourself, but ac= cept 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= om time to time. When flames are in, thought is out, I like that, good word= s to 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= hat they temporarily lose some rationality, it may be a good indication of ho= w "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= ound of discussion I think you have walked that fine line well and so I've tri= ed to 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= f update contentions with line endings. Does CVS use diffutils? Does CVS = have an option to accept various line endings? I don't know CVS that well at = all. = But if it's just files being passed around, the issue might still be ther= e. = But the files should be such a small number that it's little problem to h= andle 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 > useful". In general in life, if a person sees black or white, they miss the infini= te possible other interpretations in the grey area. It's taken many years f= or me to appreciate this. But computers know only binary, and for people to effectively program, they must think in binary (not literally, but the ri= ght 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= l process in this mode, and may exclude some possibilities or compromises. = And 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= eld 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 = we have some ambiguity. We should clarify. There are three types of differences. 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= f = > 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= ou try to pose the question to GNU, or to any of the users of software that = have used GNU software (and in particular diff) in native *nixes for 10-20 yea= rs (or however long diff existed). remind yourself, don't think of it as right or wrong. I believe your con= cerns are valid and have merit. But rather as you say, think of what is useful= , and as I say, think of what is realisticly achievable. That is the compromis= e is an integral part of consensus. ;-) I think the envvar or conf file migh= t be realistically achievable because of much less resistance. Then you can configure the default behavior, without forcing other people to change th= eir opinion about what should be the official, compiled default. This is one of those common, essential, unspoken, assumed ways of thinkin= g in *nix. Nothing will suit everyone, so give me options and I will use them= =2E = Never rely on defaults, but rather define my preferred behavior for a giv= en program with options. > This are my reasons. I do not know if I have been sufficiently short an= d = > clear. 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, = so tell me. It may just be a good exercise to practice discipline and preci= sion when working with computers. Without these things, programmers are likel= y to 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= ior, 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= t. = 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= is.) Err, I did not test my test cases, I just invented them and followed the = same format as Earnie's. :p May need tweaking. But also, it's not a complet= ely exhaustive test of diff, and currently diff does not seem to respond well= to carriage-return all by itself, or at end of file. More comprehensive tes= t cases might be indicated. The number can get ridiculously high as I thin= k of 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 = not adjacent to the first or last line. 5 lines per file, 3 unique, 2 repeat= ed, 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= nd last to \n (as \r and \r\n were tested earlier). Comes down to 6 files a= gain. 30 more tests. 66 tests for diff, to be fairly certain about how it might respond in eve= ry possible scenario. But that's just line endings. There might be embedded null or non-printa= ble characters which make diff treat it differently, no idea what -a might do= =2E.. 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= any of these combinations, thus reduce the number of files back to a sane lev= el less than 10. Sorry for verbosity, thinking out loud. Leif |
From: Greg C. <chi...@co...> - 2005-10-12 15:56:54
|
On 2005-10-12 13:24 UTC, Leif W wrote: > > 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) I had never noticed the '--strip-trailing-cr' option before, and it doesn't seem to have come up in this discussion until now. It sounds very much like this idea: On 2005-8-5 14:15 UTC, Earnie Boyd wrote: > 4) Treat \n and \r\n as different unless some special switch is applied It doesn't seem to be implemented in MSYS's diff: diff: unrecognized option `--strip-trailing-cr' diff - GNU diffutils version 2.7 but the manual you cite is for version 2.8.1, so maybe porting a later version of diffutils to MSYS would resolve the issue in the way the majority seems to prefer. |
From: Lennart B. <len...@st...> - 2005-10-12 20:50:55
|
Greg Chicares wrote: >It doesn't seem to be implemented in MSYS's diff: > > diff: unrecognized option `--strip-trailing-cr' > > diff - GNU diffutils version 2.7 > >but the manual you cite is for version 2.8.1, so maybe porting a >later version of diffutils to MSYS would resolve the issue in the >way the majority seems to prefer. > > I am not sure. Perhaps that depends on the decisions made in the configure process? After having a look at the build process for MSYS packages, the difficulties with updating those packages, the problems with portability, the choices for the rules on w32, the differences between GnuWin32 tools and MSYS dito, ect -- then I am beginning to wonder what I am actually doing! A while ago someone (sorry I forgot the name) said that some of the GnuWin32 tools can be used together with MSYS. I asked which tools but we did not find a clear answer. Maybe it would be good to look into this very carefully? I have got the impression that the GnuWin32 tools are compiled right out of the box -- with the help of MinGW+MSYS. That is a big advantage and makes it much easier to use the most up-to-date versions of the GNU utilities. Some tools need to use the MSYS-1.0.DLL, but which are they? What requirements make this necessary? Is there for example anything that makes it better to use a diff compiled for MSYS than one compiled for native w32? I guess those starting other processes are candidates for the group that requires the MSYS-1.0.DLL. But what about those that does not start other programs? They should (at least in theory) get the file paths in native w32 format. So what is actually the reason today that there is a special MSYS version of diff (for example)? Why not try to marry MSYS+GnuWin32? The couple already seems dependent on each other... ;-) Kind regards, Lennart PS: Is there some special kind of dependence between sh and make? |