ini文件多了个dos的^M结尾符号，导致linux下脚本程序不能运行
[omcr@lnlte2dmr-tdl legacy]$ cat -A ums_del_mr_files_cfg.ini MrFileDiskMountPoint=/home^M$ MrFileDiskSpaceQuotaThresholdRatio=70^M$ MrFileReserveDayMin=7^M$ MrFileReserveDayMax=31^M$ MRF_Path=/home/mrftp/mrfile/dtmrfile^M$ MRE_Path=/home/mrftp/mrfile/MRE^M$ MRO_Path=/home/mrftp/mrfile/MRO^M$ MRS_Path=/home/mrftp/mrfile/MRS^M$ ^M$ TDMRSWITCH=OFF^M$ TDMRORIGINALFILE=/home/mrftp/tdmrfile/backup^M$ TDMRFILE=/home/mrftp/tdmr/download^M$ TDMRNORTHFILE=/home/mrftp/tdmr/mrfile^M$
在Linux下可以是用“cat –A filename” 来查看某个文件中的隐含字符，UNIX格式的话，每行结尾是 “$”符号，而DOS格式则是 “^M”符号。
这个 “^M”是怎么来的，为啥.sh脚本文件就没有？
solaris修改后的*.ini文件，换行符变成了dos模式。
为啥嘞？
是从solaris传输到windows时，ftp采用自动模式传输，实际上ftp采用ascii模式传输，结果传输的ini文件被改写了，
这个现象是使用flashfxp从solaris下载到windows才发生的，从windows上传到solaris没有这种情况，linux与windows互传也没有这种情况。
得好好研究一下ftp的ascii模式和binary模式。
ASCII模式
复制时候会进行调整，主要体现为对不同操作系统的回车/换行/结束符等进行转译。
比如，回车符号在Unix下是\n(0A)，Windows下是\r\n(0D0A)，Mac下是\r(0D)。当在一个Windows操作系统上用 ASCII方式从Unix服务器上下载文件时——无论是文本文件还是二进制文件——都会进行检测和转换：每检测到一个0A，则认为是回车符号，自动插入 0D形成Windows下的回车符。显然，如果下载的是文本文件，这种转换是很有用的——我们能在Windows下看到分行后的文本，否则我们看到的是中间夹杂着小黑方块的不换行的一堆文字；然而如果下载的是二进制文件（比如exe或rar），这种转换无异于画蛇添足，破坏了整个文件。（PS：我的FlashFXP设置的是默认，估计就是按文件的特征信息来判断是文本还是二进制，但它向linux传却用了windows的newLine符，可能是个bug吧）
-------------------------------------------------------------以下是我总结的一点儿经验------------------------------------------------------------------------------------------
从linux下载ini文本文件到windows，或从windows上传到ini文本文件linux，尽管我设置为ascii模式，但最终传输还是使用binary模式。
但windows与solaris之间传输ini文本文件时ascii模式是起作用的，不论是从windows上传到solaris，还是从solairs下载到windows：
我把一个unix格式的ini文件也通过ascii模式从windows上传到solaris，flashfxp的消息窗口还有warning警告，提示发现13出换行符有误。
如果把.ini后缀名换为.sh,则自动模式下，flashfxp采用binary模式从solaris下载到windows。看来如果让flashfxp自动判断，flashfxp不把.sh当成文件文件。
如果把传输模式设定为ascii，则从solaris下载到windows的.sh文件也会被修改换行符。
最终结论，从windows上传到solaris用自动传输模式应该是没有问题的，前提是上传的文件原来的格式是正确的。比如.sh文件上传前就应该使用UNIX换行符。
当然用ascii传输模式上传script脚本，如.sql文件，也可以二次检验一下是否使用UNIX换行符，传输过程中把发现的windows换行符都改成UNIX换行符。
但是，如果传输.jar包之类的程序文件，千万不能用ascii模式。用自动模式也行，binary模式也行，因为flashfxp的自动模式会判断传输文件的后缀是不是文本文件类型，jar包不算文本类型，所以实际传输时还是binary模式。
要是不想麻烦，就用自动模式，让程序去判断哪些是文本文件，哪些不是文本文件。
如果你明白了这个道理，就可以选定传输模式。
-------------------------------------------------------------以上是我总结的一点儿经验-----------------------------------------------------------------------------------
因此，如果服务器和客户端的OS不相同，对于ASCII文件（文本文件）采用ASCII模式下载，对于非文本文件采用BINARY模式下载；如果两端OS相同，两种方式具有同样效果。
如何解决：
有些经常游走在两个OS之间的人员采取的习惯做法是：将在Windows下编辑的文件转换成Unix模式，而FTP默认用BINARY模式传输。（PS：最终我也选择这种模式，好处两点，1newLine符我控制，清晰；2不用ascii方式的转换，速度也快）。
http://blog.chinaunix.net/uid-20546486-id-4256823.html
Linux上如何进行换行符转换
https://wdp107.iteye.com/blog/892133
文件
