From: <rr...@cs...> - 2005-08-07 15:39:29
|
> Others have asked that \r\n be treated equivalent to \n even though >in reality the files are different. What I think you need is an option. GNU diff already has an option, "--binary", to *not* treat CRLF as the same as just LF, because normally the plain Win32 version of diff treats them as being identical. Ross Ridge |
From: <mo...@rq...> - 2009-02-27 18:57:31
|
Sorry if this is an obvious question, but whatever happened with this discussion from 2005? http://osdir.com/ml/gnu.mingw.msys/2005-08/msg00037.html I saw that the mailing list sign-up page wants to direct discussion to this mailing list rather than the msys-specific one, so I'm sending it here and apologize if this is the wrong place. I am very frustrated by this and can't see anything obvious in "diff --help" that says "ignore DOS linefeed". I am pulling source down from a unix-based project, trying to make changes on my windows system, and create diffs to submit via bugzilla back to the project. Am I missing something, some command line that does what I want? Or did the discussion of enhancing diff back in 2005 die out and nothing happened? Thanks for your time! Monk. |
From: Greg C. <gch...@sb...> - 2009-02-27 19:08:09
|
On 2009-02-27 18:06Z, mo...@rq... wrote: > > http://osdir.com/ml/gnu.mingw.msys/2005-08/msg00037.html [...] > I am very frustrated by this and can't see anything obvious in "diff > --help" that says "ignore DOS linefeed". I am pulling source down from a > unix-based project, trying to make changes on my windows system, and > create diffs to submit via bugzilla back to the project. If there's no such option, but you want to strip carriage returns: tr --delete '\r' |
From: Earnie B. <ea...@us...> - 2009-02-27 21:27:41
|
Quoting Greg Chicares <gch...@sb...>: > On 2009-02-27 18:06Z, mo...@rq... wrote: >> >> http://osdir.com/ml/gnu.mingw.msys/2005-08/msg00037.html > [...] >> I am very frustrated by this and can't see anything obvious in "diff >> --help" that says "ignore DOS linefeed". I am pulling source down from a >> unix-based project, trying to make changes on my windows system, and >> create diffs to submit via bugzilla back to the project. > > If there's no such option, but you want to strip carriage returns: > tr --delete '\r' > In the original version of MSYS diff I had modified the source to treat \r as whitespace when the ignore whitespace switch was set. If you're using vim set ff=unix when editing the file. I often add a // vim:ft=c:sts=2:sw=2:ts=2:et:ai:sta:ff=unix to the end of the file while I'm editing it. You'll need to change the options to fit the standards for the project. But always on windows you should set ff=unix so you don't have to worry about the wrong line ending; you just remove the vim helper hunk from the diff file. Also don't convert line endings when your using VCS tools built in GUI formats. Earnie |
From: <mo...@rq...> - 2009-02-28 00:53:30
|
Yeah, I would have done the whitespace ignoring but I actually was trying to diff a file that had whitespace differences (formatting the output when --help was passed to the utility) so that didn't work out for me. I am using the Windows environment so of course I shun vi, vim, emacs, pico, and most of the unixy tools in msys. I had hoped that Wordpad would not add the extra return character, but it does in XP. Win2K it didn't. And yeah, if I get really lazy I might try editing stuff in Notepad. I'm a very casual and unskilled programmer and I readily admit that, but I do know that the whole dos/unix linefeed issue has been around forever. I had just hoped that after so much time there'd be more consideration for this type of stuff on something like msys which seems like it should take dos/unix eol characters into consideration seeing how it's reproducing a unixy environment on Windows. I hope in the future you'll consider adding some option/argument to diff to ignore the DOS-specific linefeed if the user wants to go that route. I'd argue that it's probably a good feature to have upstream in the main GNU diff as well, but I find that unix developers typically go out of their way to show how much they don't care about windows-specific issues, which is a shame. I'm going to end up solving this problem elsewhere or with an additional program/utility (probably something in my svn client which was also creating horrible diffs/patches), so I won't take up anymore email space with this issue. I do thank you for the responses, though! And I do implore you to consider making diff a bit more friendly to windows programmers who work with unix code--it can't be that hard to modify diff (says the non-programmer) but it seems like it'd save people some grief. Again, thanks for your time! Monk. >>> http://osdir.com/ml/gnu.mingw.msys/2005-08/msg00037.html >> [...] >>> I am very frustrated by this and can't see anything obvious in "diff >>> --help" that says "ignore DOS linefeed". I am pulling source down from >>> a >>> unix-based project, trying to make changes on my windows system, and >>> create diffs to submit via bugzilla back to the project. >> >> If there's no such option, but you want to strip carriage returns: >> tr --delete '\r' >> > > In the original version of MSYS diff I had modified the source to treat > \r as whitespace when the ignore whitespace switch was set. > > If you're using vim set ff=unix when editing the file. I often add a > // vim:ft=c:sts=2:sw=2:ts=2:et:ai:sta:ff=unix to the end of the file > while I'm editing it. You'll need to change the options to fit the > standards for the project. But always on windows you should set > ff=unix so you don't have to worry about the wrong line ending; you > just remove the vim helper hunk from the diff file. Also don't convert > line endings when your using VCS tools built in GUI formats. > > Earnie |
From: Roumen P. <bug...@ro...> - 2009-02-28 09:29:42
|
mo...@rq... wrote: > Yeah, I would have done the whitespace ignoring but I actually was trying > to diff a file that had whitespace differences (formatting the output when > --help was passed to the utility) so that didn't work out for me. > > I am using the Windows environment so of course I shun vi, vim, emacs, > pico, and most of the unixy tools in msys. I had hoped that Wordpad would > not add the extra return character, but it does in XP. Win2K it didn't. > And yeah, if I get really lazy I might try editing stuff in Notepad. May be Notepad++ ? > [SNIP] > I hope in the future you'll consider adding some option/argument to diff > to ignore the DOS-specific linefeed if the user wants to go that route. > I'd argue that it's probably a good feature to have upstream in the main > GNU diff as well, but I find that unix developers typically go out of > their way to show how much they don't care about windows-specific issues, > which is a shame. The GNU diff has an options --strip-trailing-cr. [SNIP] |
From: Earnie B. <ea...@us...> - 2009-02-28 14:26:23
|
Quoting mo...@rq...: I have one thing to say to you. > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. > > Most annoying abuses are: > 1) Top posting > 2) Thread hijacking > 3) HTML/MIME encoded mail > 4) Improper quoting > 5) Improper trimming I will continue to do this until everyone learns. Earnie |
From: Earnie B. <ea...@us...> - 2009-02-28 14:29:13
|
Quoting mo...@rq...: > I am using the Windows environment so of course I shun vi, vim, emacs, > pico, and most of the unixy tools in msys. I had hoped that Wordpad would > not add the extra return character, but it does in XP. Win2K it didn't. > And yeah, if I get really lazy I might try editing stuff in Notepad. > Vim has a GUI version they named gvim. It is very useful for programming tasks such as program file modification. Earnie |
From: Charles W. <cwi...@us...> - 2009-02-28 18:55:36
|
Earnie Boyd wrote: > Quoting mon...@pu...: > >> I am using the Windows environment so of course I shun vi, vim, emacs, >> pico, and most of the unixy tools in msys. I had hoped that Wordpad would >> not add the extra return character, but it does in XP. Win2K it didn't. >> And yeah, if I get really lazy I might try editing stuff in Notepad. >> > > Vim has a GUI version they named gvim. It is very useful for > programming tasks such as program file modification. I find that NotePad++ (free as in speech, free as in beer) is a pretty good notepad replacement that understands line endings as God intended (that is, unix) although you can use the devil's line endings if you must, and doesn't add anything to files that I didn't type. -- Chuck |
From: Earnie B. <ea...@us...> - 2009-02-28 14:32:48
|
Quoting mo...@rq...: > I'm a very casual and unskilled programmer and I readily admit that, but I > do know that the whole dos/unix linefeed issue has been around forever. I > had just hoped that after so much time there'd be more consideration for > this type of stuff on something like msys which seems like it should take > dos/unix eol characters into consideration seeing how it's reproducing a > unixy environment on Windows. > It was a conscious decision to open all files in binary mode in MSYS. It helps identify things like invalid line endings in a diff file. Note that a file that has changed from \n line endings to \r\n line endings is different and the MSYS diff correctly reports it. Earnie |
From: Xochitl L. <Xoc...@tr...> - 2009-03-02 15:34:46
|
> I'm going to end up solving this problem elsewhere or with an additional > program/utility (probably something in my svn client which was also > creating horrible diffs/patches), so I won't take up anymore email space > with this issue. If you have SVN diff, have you tried invoking it with options similar to this? $> svn diff -x -u -x -b -x --ignore-eol-style . > mychanges.patch This works on my Mac for generating diffs which mostly ignore XCode's (the Visual Studio "equivalent" for Mac) line changes to our Linux/Windows-developed source. "-u" should just be the patch file format type of "unfied." "-b" would be ingorning space changes, "--ignore-eol-style" would be ingoring end-of-line changes. Probably you can invoke the regular diff program with similar "-u -b --ignore-eol-style" options and get close to the same output. You shoud be also able to add more diff options ($> man diff) to svn diff by making more use of the "-x" option to svn diff. |
From: Lorenzo B. <be...@ds...> - 2009-04-23 09:15:12
|
Greg Chicares wrote: > On 2009-02-27 18:06Z, mo...@rq... wrote: >> http://osdir.com/ml/gnu.mingw.msys/2005-08/msg00037.html > [...] >> I am very frustrated by this and can't see anything obvious in "diff >> --help" that says "ignore DOS linefeed". I am pulling source down from a >> unix-based project, trying to make changes on my windows system, and >> create diffs to submit via bugzilla back to the project. > > If there's no such option, but you want to strip carriage returns: > tr --delete '\r' is tr a standard program? I mean can its presence be assumed, or should it be checked for? thanks in advance Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Greg C. <gch...@sb...> - 2009-04-23 16:58:31
|
On 2009-04-23 09:14Z, Lorenzo Bettini wrote: > Greg Chicares wrote: >> On 2009-02-27 18:06Z, mo...@rq... wrote: >>> http://osdir.com/ml/gnu.mingw.msys/2005-08/msg00037.html >> [...] >>> I am very frustrated by this and can't see anything obvious in "diff >>> --help" that says "ignore DOS linefeed". I am pulling source down from a >>> unix-based project, trying to make changes on my windows system, and >>> create diffs to submit via bugzilla back to the project. >> >> If there's no such option, but you want to strip carriage returns: >> tr --delete '\r' > > is tr a standard program? > I mean can its presence be assumed, or should it be checked for? I think it's safe to assume tr(1) is available in just about any *nix environment. It's in MSYS, it's part of gnu coreutils, and it's in SUSv2: http://opengroup.org/onlinepubs/007908775/xcu/tr.html It's not part of msw: C:\WINDOWS>tr 'tr' is not recognized as an internal or external command, operable program or batch file. but you're already using 'diff' so I suppose that wouldn't matter to you. |
From: Lorenzo B. <be...@ds...> - 2009-04-26 14:24:26
|
Greg Chicares wrote: > On 2009-04-23 09:14Z, Lorenzo Bettini wrote: >> Greg Chicares wrote: >>> On 2009-02-27 18:06Z, mo...@rq... wrote: >>>> http://osdir.com/ml/gnu.mingw.msys/2005-08/msg00037.html >>> [...] >>>> I am very frustrated by this and can't see anything obvious in "diff >>>> --help" that says "ignore DOS linefeed". I am pulling source down from a >>>> unix-based project, trying to make changes on my windows system, and >>>> create diffs to submit via bugzilla back to the project. >>> If there's no such option, but you want to strip carriage returns: >>> tr --delete '\r' >> is tr a standard program? >> I mean can its presence be assumed, or should it be checked for? > > I think it's safe to assume tr(1) is available in just about any *nix > environment. It's in MSYS, it's part of gnu coreutils, and it's in SUSv2: > http://opengroup.org/onlinepubs/007908775/xcu/tr.html > Actually, it is also used inside autoconf generated configure, so I think I can use it :-) however, the funny thing is that if I use it from a Makefile, say tr -d '\r' < original.txt > modified.txt everything works fine... if I use from a shell script invoked from the Makefile, then > operator still appends '\r', so it becomes useless... pretty strange -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: <mo...@rq...> - 2009-02-28 00:57:24
|
Thanks for the heads-up. Kind of a poor-man's dos2unix, heheh! Monk. > On 2009-02-27 18:06Z, mo...@rq... wrote: >> >> http://osdir.com/ml/gnu.mingw.msys/2005-08/msg00037.html > [...] >> I am very frustrated by this and can't see anything obvious in "diff >> --help" that says "ignore DOS linefeed". I am pulling source down from >> a >> unix-based project, trying to make changes on my windows system, and >> create diffs to submit via bugzilla back to the project. > > If there's no such option, but you want to strip carriage returns: > tr --delete '\r' > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > -- > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. > > Most annoying abuses are: > 1) Top posting > 2) Thread hijacking > 3) HTML/MIME encoded mail > 4) Improper quoting > 5) Improper trimming > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Earnie B. <ea...@us...> - 2009-02-28 14:25:15
|
Quoting mo...@rq...: I have one thing to say to you. > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. > > Most annoying abuses are: > 1) Top posting > 2) Thread hijacking > 3) HTML/MIME encoded mail > 4) Improper quoting > 5) Improper trimming I will continue to do this until everyone learns. Earnie |