为什么在使用Meld修改后将^ M添加到script.r？

Question

尊敬的Meld和Emacs / ESS用户，

我做了什么：

1. 使用Emacs / ESS创建script.r。
2. 通过从another_script.r
中提取一些代码行来对script.r进行一些修改
3. 在Emacs / ESS中重新打开another_script.r（或script.r）以继续工作。

另一个不的another_script.r中的所有行被推送到script.r以^ M结尾

有时候反过来 - 只有被推/拉的线以^ M＆＃39结束。到目前为止，我还没有确切地确定哪个动作决定了^ M'的放置位置。无论哪种方式，我仍然会在整个地方找到^ M，并且我希望在使用Meld之后避免使用它们！

FWIW：该目录正由Dropbox同步;在Meld，首选项＆gt;编码标签，＆＃34; utf8＆＃34;在文本框中输入;所有操作都在Linux（Ubunt 12.04）下使用Meld v1.5.3，Emacs v23.3.1进行

当前的解决方法是在终端中运行：dos2unix /path/to/script.r，它会删除^M。但这不应该是必要的，我希望这里有人可以告诉我如何避免这些。

干杯。

Answer 1

在我运行cat script.r | hexdump -C | head的终端中，在返回的输出中找到0d 0a，这是新行的DOS格式（回车0d后紧跟换行符{{ 1}}）。我在another_script.r上运行了相同的命令，我正在合并但只观察0a，没有0a，表示Unix格式化。

要进一步检查这是否是^ M行结尾的来源，script.r已通过0d 0a＆amp;转换为unix格式。已验证dos2unix script.r已使用hexdump -C转换为0d 0a，如上所述。我使用Meld进行合并，尝试复制在我的脚本中产生^ M行结尾的过程。我重新选择了Emacs / ESS中的两个文件，发现没有^ M行结尾。没有将script.r 返回转换为dos格式并重复上述过程以查看^ M行结尾是否重新出现，我相信我已经解决了我的^ M问题，就是这样，我不知道的是，我的一个文件是dos格式化的。我带回家的消息：在Windows主导的环境中，永远不要假设一个人的个人Linux环境不包含DOS位。或行结尾。