bdkjones / CodeKit2

CodeKit 2 Beta
97 stars 4 forks source link

Possible line ending issue on concatenation of js files. #219

Closed rpkoller closed 10 years ago

rpkoller commented 10 years ago

I've taken three js files, directly as is from their repositories:

bildschirmfoto 2014-01-31 um 21 32 42 bildschirmfoto 2014-01-31 um 21 32 57 bildschirmfoto 2014-01-31 um 21 33 25

the js settings in codekit are as follows:

bildschirmfoto 2014-01-31 um 21 33 50

i've deleted the old output file before i reran the processing. when opening the new outputfile i get:

bildschirmfoto 2014-01-31 um 21 34 43

the line endings of the new outputfile are now windows like in the modernizer screenshot.

bildschirmfoto 2014-01-31 um 21 42 34

the redish line endings shown in the last screenshot turn up in the parts of picturefill and jrespond (the ones which had unix line endings in their screenshots of their raw source files).

Running on 10.8 , coda 2.0.13 , and codekit beta 14

bdkjones commented 10 years ago

Okay. So here's what I did:

1) Downloaded the "picturefill.js" repo from GitHub. (Using the code from your example.) 2) Duplicated "picturefill.js" twice, then renamed each file to "p1.js", "p2.js" and "p3.js". 3) Added the folder to CodeKit as a project. 4) Selected "p1.js", then dragged the other two JS files to append them to p1.js. 5) Made sure the file was set to NOT minify, but to simply combine imports. 5) Hit "Process" at the bottom of the CodeKit window.

The resulting output file was "p1-ck.js". I then ran that file through an Octal dump to have each character in it spit out in fully-escaped format. The command to do this is:

od -c [filename]

Assuming you cd to the folder containing the file. The output of this command looks like this:

screen shot 2014-02-02 at 22 27 19

The CRLF sequence would be represented by \r \n in the output. I find ZERO \r characters in the entire output. The only newline character you'll see is \n, which, when it appears by itself, is the Unix LF line terminator.

So, whatever is adding CRLF sequences to your files is not CodeKit.

bdkjones commented 10 years ago

Note: CodeKit EXPECTS Unix line endings in your files. If you START with a file that has CRLF line endings (which is entirely possible if you're working with a file that was saved on Windows), CodeKit will simply add LF line endings for the lines it adds to the combined output file (around the comment blocks that mark the start of each combined file). It will NOT modify the existing line endings. In that case, it's entirely possible to end up with a mixed-line-ending file.

This is almost definitely what's happening in your case. The CRLF are the most common line endings because that's what the file started with and CodeKit added a few LF line endings around its comment blocks in the output file.

bdkjones commented 10 years ago

Also: Be careful about relying on the "invisible characters" in editors. The only reliable way to determine which line endings are being used is to do an octal dump, as explained above.

rpkoller commented 10 years ago

thanks for the info about the octal dump. will use it from now on for debugging if i run into issues.

and about the scenario. i guess the issue was that the development modernizer build has crlf line endings while my other includes had all unix lf ones. somehow things must been mixed up since the resulting js file stuck to the crlf too. with a fresh downloaded modernizer build it hasnt happened again yet. if the input of picturefill has a lf ending and modernizer has a crlf the resulting js file has lf too and not crlf too like in my screenshot above. could stay closed then for now.