Closed rpkoller closed 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:
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.
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.
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.
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.
I've taken three js files, directly as is from their repositories:
the js settings in codekit are as follows:
i've deleted the old output file before i reran the processing. when opening the new outputfile i get:
the line endings of the new outputfile are now windows like in the modernizer screenshot.
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