[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13705: 24.2.93; "^M" characters in diff buffers
From: |
Eli Zaretskii |
Subject: |
bug#13705: 24.2.93; "^M" characters in diff buffers |
Date: |
Wed, 13 Feb 2013 23:44:21 +0200 |
> Date: Wed, 13 Feb 2013 19:59:23 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13705-done@debbugs.gnu.org
>
> > (let ((coding-system-for-read 'no-conversion))
> > (call-process shell-file-name nil t nil
> > shell-command-switch "diff -c fa fb"))
> >
> > and look at the lines generated by Diff, like these:
> >
> > *** fa 2013-02-12 18:41:03.201375000 +0200
> > --- fb 2013-02-08 16:25:03.161000000 +0200
>
> The above expression produces the output shown in
> "Screenshot-MS-Windows.png" (attached).
As expected.
> Yes, the problem seems to be the one you've spotted, but note that
> I've just reproduced the exact same problem on Ubuntu [1]. See the
> screenshot "Screenshot-Ubuntu.png" (attached).
On Ubuntu, it is expected to see the ^M characters, because that's
what you'd see if you invoke Diff from the shell prompt as well.
IOW, on Windows, two files which have DOS EOLs should not show ^M in
the Diff output, because DOS EOLs are native on Windows, and ^M at the
end of the line is not considered part of the text there. On Unix,
files with DOS EOLs are expected to be seen with the ^M explicit,
because it _is_ part of the text.
> Therefore, the problem seems to be more general: it affects to every
> diff made from two files with DOS-type EOLs, unless the "diff" program
> is adapted to deal with this scenario (like the one from GnuWin32).
It _is_ general, but it is not a problem. When Emacs sees
inconsistent EOL format it _always_ refrains from decoding the EOLs.