跨平台开发下换行符CRLF和LF的问题

在跨平台下开发应用，首先应该考虑的是各种兼容性的问题，这里讨论在windows和linux下联合开发而导致换行符不兼容的问题：

linux操作系统下的换行符为/n，而windows操作系统下的换行符则为/r/n，这导致在程序执行的时候会出现一些问题，下面举个我遇到的问题和解决方法：

问题描述：

在windows下编写的shell脚本，通过FileZilla上传到linux服务器上执行时，会出现/r的命令不存在的错误，这是因为linux下的shell脚本只识别/n为换行符，而把/r当做程序的指令，这样就会出现脚本运行不成功的现象。

解决办法：

（1）Git可以在你提交时自动地把行结束符CRLF转换成LF，而在签出代码时把LF转换成CRLF，从而实现两操作系统的兼容性。可以用core.autocrlf来打开此项功能， 如果是在Windows系统上，把它设置成 true，这样当签出代码时，LF会被转换成CRLF：执行命令：git config --global core.autocrlf true

 

（2）把core.autocrlf设置成input来告诉Git在提交时把CRLF转换成LF，签出时不转换：执行命令：git config --global core.autocrlf input

 

（3）如果你是Windows程序员，且正在开发仅运行在Windows上的项目，可以设置false 取消此功能，不进行变换，也就是一直是CRLF。把回车符记录在库中：执行命令：git config --global core.autocrlf input

下面我以shami项目中的generate_api_doc.sh文件为例做这三个实现

在windows本地文件大小为347B（CRLF），而在github上的代码大小为320B（LF）

实验（1）：

   在git上使用指令git config --global core.autocrlf true 可以打开该功能，

   然后使用指令git checkout generate_api_doc.sh 可以重新检出这个文件（文件动过才能刷新成功）

   文件大小就变成347B

 

实验表明（2）：

   在git上使用指令git config --global core.autocrlf input 可以打开该功能，

   然后使用指令git checkout generate_api_doc.sh 可以重新检出这个文件（文件动过才能刷新成功）

   文件大小就变成320B

 

实验表明（3）：

在git上使用指令git config --global core.autocrlf false 可以打开该功能，

   然后使用指令git checkout generate_api_doc.sh 可以重新检出这个文件（文件动过才能刷新成功）

   文件大小就变成347B

注：

（1）git config core.autocrlf 可以查看状态

（2）文件动过才能刷新成功的意思就是文件检出一次后，需要有修改才能再次检出成功，为了实验成功，可以用linux下的文件   覆盖windows的文件，再进行checkout操作