google彷佛把ADB输出的回车换行问题改掉了

google改动内容在这儿，没有测试过，看起来没问题。

到目前位置，市面上全部的Android设备，都存在这个这个小问题：

在Linux/Mac上执行adb命令输出什么东西时，就算是二进制输出，那么LF(0x0a)字符会被转换成CR(0x0d) + LF。Windows上更好笑，会变成CR+CR+LF。

这个很好验证:

从Android上抓一个文件下来，例如/default.prop, 看看里面应该只有LF(0x0a)，而没有CR(0x0d)的。

adb pull /default.prop     local_output_file1

而后在经过adb shell cat命令输出到本地，看看文件里是否是多了好多CR(0x0d)了。

adb shell cat /default.prop > local_output_file2

这个不是简单的由于Windows OS的缘故，Linux也出毛病。

解决方法一大堆，例如上述的pull，或者经过socket输出到PC。

其实还有方法能够彻底不须要转换，也不须要pull,socket什么的。首先总结缘由是两个：

1. Android那边首先作了LF->CR+LF的转换。具体的在ASOP代码里有，adbd用了pty这东西来作输入输出。很古老的东西，没什么兴趣说，google最近改掉了。

2. Windows OS这边的adb工具更额外作了一层LF->CR+LF的转换。这个到是Windows的默认风格。

解决方法有两个步骤(Linux/Mac只要第一个步骤就好了)

1. 在android那边设定stty -onlcr来禁止发自android那边的转换。

这个也有两个方法，一个是借助于外部工具stty(从busybox里来的)，那么

预先把busybox工具放到android里：

adb push busybox /data/local/tmp/
adb shell chmod 755 /data/local/tmp/busybox

而后，那就是在执行本身的命令以前执行busybox stt -onlcr。例如

adb shell '/data/local/tmp/busybox stty -onlcr; cat /default.prop' > local_output_file2

还有一种方法就是本身的C代码里，执行这一段：

#include <termios.h>
if (isatty(STDOUT_FILENO)) {
    struct termios term;
    tcgetattr(STDOUT_FILENO, &term);
    cfmakeraw(&term);
    tcsetattr(STDOUT_FILENO, TCSANOW, &term);
}

2. Windows这边才须要这个步骤。那就是不直接使用adb工具了，而是直接和adb工具所服务的5037端口打交道，发送命令，取得结果，这个具体的提及来有点啰嗦，若是是nodejs，那么用adbkit好了，其余的我没多看，大体就是

1. 向localhost:5037 发送host:transport:设备序列号
    获得回答，若是是OKAY四个字那就到step2，不然就错误。 
2. 继续向上述port发送shell:命令内容
    获得回答，若是是OKAY四个字那就到step2，不然就错误。 
而后从这个链接里可以读到原始的输出。