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，不然就錯誤。 
而後從這個鏈接裏可以讀到原始的輸出。