Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-2825458 ] Undocumented/broken patch.exe behavior in MSYS 1.0.11
|
From: SourceForge.net <no...@so...> - 2009-07-30 02:03:15
|
Bugs item #2825458, was opened at 2009-07-22 14:30 Message generated for change (Comment added) made by cstrauss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2825458&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MSYS Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: njerald (njerald) Assigned to: Cesar Strauss (cstrauss) Summary: Undocumented/broken patch.exe behavior in MSYS 1.0.11 Initial Comment: It appears that patch.exe included with MSYS 1.0.11 does not handle newline conversions anymore. This is a significant and undocumented behavior change from patch.exe in MSYS 1.0.10, which automatically converted between UNIX and windows newline conventions. Even worse, when the new patch.exe encounters this situation, it DOES perform CR-LF conversion while creating its reject file, making it impossible to determine from the reject file that the failure was caused by newline conventions. There was another ticket about this before, but the response was basically take-it-or-leave-it. At the very least, MSYS release notes should be updated to mention this behavior change, because patch processes that were working under MSYS 1.0.10 have broken after switching to MSYS 1.0.11, and the improper reject files make it very frustrating to troubleshoot. ---------------------------------------------------------------------- >Comment By: Cesar Strauss (cstrauss) Date: 2009-07-29 23:03 Message: The MSYS version of GNU Patch was not modified in any way from the original sources. In fact, the exact same behavior can be seen on Linux as well. According to the manual of GNU Patch, this seems to be intentional: "patch tries to skip any leading garbage, apply the diff, and then skip any trailing garbage. Thus you could feed an article or message containing a diff listing to patch, and it should work. If the entire diff is indented by a consistent amount, or if a context diff contains lines ending in CRLF or is encapsulated one or more times by prepending "- " to lines starting with "-" as specified by Internet RFC 934, this is taken into account." Reference: http://linux.die.net/man/1/patch It seems that GNU Patch tries to be helpful by determining if the patch was translated from LF to CRLF on transmission, and translating it back to LF before applying. This is possible because, on a standard patch file, the header lines always use LF endings, even if the patch itself contains CRLF. This explains why you see LF endings on the reject files, since the patch itself was already translated at input. On the other hand, in the latest alpha version of GNU Patch: "The --binary option disables the heuristic for stripping CRs from line endings in patches." Reference: http://savannah.gnu.org/forum/forum.php?forum_id=5714 Perhaps this option should be enabled by default? Regards, Cesar ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-07-28 10:11 Message: 1) Reject file does not keep the \r\n line ending 2) If patch file contains \r\n and source file contains \n the patch should patch the source with the line ending \r\n retained in the changed lines and \n in the remaining source lines. 3) If patch file contains \n and the source file contains \r\n the patch should patch the source with the line ending \n retained in the changed lines and \r\n in the remaining source lines. Cesar, were changes made specifically to patch to make these fail? Were changes attempted to bring the patch file line ending to be the same as the source file line ending? IMO, that would be incorrect behavior. ---------------------------------------------------------------------- Comment By: njerald (njerald) Date: 2009-07-28 04:15 Message: I've attached a zip with a batch file to demonstrate the problem in MSYS 1.0.11. Four scenarios: patch FAILS (incorrectly) using DOS-style input file with DOS-style patch; reject file is UNIX-style (incorrect). patch FAILS (correct, strictly speaking) using DOS-style input file with UNIX-style patch; reject file is UNIX-style (correct). patch SUCCEEDS (incorrectly, strictly speaking) using UNIX-style input file with DOS-style patch. patch SUCCEEDS (correctly) using UNIX-style input file with UNIX-style patch. Note that patch in MSYS 1.0.10 succeeds in all four scenarios. ---------------------------------------------------------------------- Comment By: Cesar Strauss (cstrauss) Date: 2009-07-23 20:27 Message: I agree this change should be mentioned in the release notes. Thank you for bringing my attention to it, and sorry for the inconvenience. I tried, but was unable to create an improper reject file. Could you please attach a simple example, so that I can debug this? For instance, a small text file, a patch, and the resulting improper reject file. Thanks, Cesar ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2825458&group_id=2435 |