I have got 3 unix boxes A B C. Box A is being used to prepare some reports. After the reports generation, Box A sftp the reports to Box B and Box C. When I look at the report in Box B and Box C. The reports are different. In Box B, I see using od -x command there is CRLF (\r\n) at the end of each line. Whereas in Box C, the hexa version of report displays only LF (\n).
Do you know what might the reason of having two different behaviours, when the boxes are of same setup and the transfer mode is same. Is there still could be some setup related to SSH or SFTP, which affects the way we get CRLF?
The output in Box B is correct i.e. I want to have CRLF after transfer visible in the report. How can I make sure to do this during transfer or somewhere in the setup so that I could bring consistency in both the servers and always get CRLF in the report?
The problem is - obviously - a DOS/Unix conversion taking place in the one case but not in the other. There might be several places to look for a remedy (i suppose you have already checked the transfer mode itself), here is one:
Some ftp clients have a "auto" option where they try to guess if to transfer in binary or ASCII mode. Maybe the heuristics on one box lead to different results than on the other. Maybe they are based on /etc/magic and this file is different.
It might help to enforce binary - or, depending on the desired result, ASCII - mode explicitly to get consistent results.
Hello
The method of transferring the file is same in both the servers. But still I am not able to notice the different settings in both the target servers.
Please suggest any tips where could I look for the difference in server configurations. /etc/magic is identical in both of them.
Could their be any difference in the way SSH Keys are generated to access target servers from single source server. Is there any possibility that one target server is putting CRLF and another is applying only LF - due to the ways public/private key pairs are generated?