macOS Wrong Line Endings (CRLF vs LF)?

[RedReplicant]

I've started having a problem lately - every time I write a sh file it ends up having the wrong line endings after I upload it to my Linux box via FTP so I get this when I try and run it:

x@x ~/xxx $ ./update_rrd_db.sh 
-bash: ./update_rrd_db.sh: /bin/bash^M: bad interpreter: No such file or directory

when I change the file mode to unix in vim it runs fine, and when I copy the file back across FTP and right back it works fine, until I edit it in Brackets or Sublime Text, then it somehow gets the carrage return back in the file. Wtf? I haven't changed anything in my setup anywhere and I haven't changed programs/ftp settings/etc.

 

[chown33]

Make a test case using Brackets and Sublime Text, and every other tool you use in the entire process.

Make sure you look at the contents of the file at every step along the way. You can use the command-line tool 'hexdump' in Terminal, or the GUI tool HexFiend, to look at the file and discover exactly when and where the CRs are inserted.

You should be able to find similar tools on Windows and/or Linux. Or worst case you could write one using a portable language like perl or Python. A hex dumper is a typical exercise or homework problem for introductory programming.

As with all debugging, Break Things Down, and Confirm Your Expectations. Breaking things down means ensuring that every processing point, be it text editor or FTP or other transfer, has its input and output examined. Confirming expectations means you should map out what line-endings you expect as input and output for each step, so you correctly identify when the deviation actually occurs.

The first place I'd start in Breaking Things Down is the text editors themselves. Specifically, the Preferences window or pane, where one would expect to set a line-ending preference. Also check the user guides or help for the editors, and search for settings about line endings. It might be hidden in some unexpected place in the GUI.

Also be sure to look at any hidden settings (the "defaults" command) that those editors might have. It could be a per-user setting, in which case create a new user account and try the editors in that account.

 

[RedReplicant]

Good call, it turns out that somehow Filezilla started treating files ending in .sh as ASCII transfers, rather than binary. Because of this it was adding CR before the LF at the end of lines. How this happened... I have no idea.