Saving sh files always uses Windows line breaks

[core-ai-bot]

Issue by vesrah
Saturday Feb 14, 2015 at 03:15 GMT
Originally opened as adobe/brackets#10594

---

Brackets 1.1.0-15558 / OSX 10.10

Creating or editing a .sh file and trying to run it comes back with:
/bin/bash^M: bad interpreter: No such file or directory
If you open the file in vim, set the file format to unix, and save it then the script works fine. Reopening the file in brackets and saving it will cause the issue to happen again.

[core-ai-bot]

Comment by redmunds
Saturday Feb 14, 2015 at 20:56 GMT

---

@vesrah PR #10346 makes line endings a preference, but that has not yet been merged.

Currently, Brackets should call the FileUtils.sniffLineEndings() and re-use the same line endings for a file being edited. For new files it calls FileUtils.getPlatformLineEndings(), so you can edit that file locally to hard-code line endings.

[core-ai-bot]

Comment by vesrah
Saturday Feb 14, 2015 at 21:16 GMT

---

I pulled the code and ran the setup_for_hacking.sh - success with that PR. Thank you!

[core-ai-bot]

Comment by peterflynn
Wednesday Feb 18, 2015 at 08:14 GMT

---

@vesrah You shouldn't need to hack the code for this to work correctly. The file is more than one line long before you open it in Brackets, right? Brackets should auto-detect the existing line endings and preserve those when saving. The FileUtils.getPlatformLineEndings() code only comes into play when there are no line endings available to detect...

Could you use Debug > Show Developer Tools to put a breakpoint in FileUtils.sniffLineEndings() and see what the actual line endings are that it's seeing in the first 1000 bytes of the file?

[core-ai-bot]

Comment by MarcelGerber
Sunday Feb 22, 2015 at 12:14 GMT

---

Now that you mentioned the first 1000 bytes: It's also possible that the first line of his file is longer than 1000 chars.
Ok, that may be unlikely for a .sh file, but it also means that minified files will almost always be converted to platform line breaks.

[core-ai-bot]

Comment by peterflynn
Tuesday Feb 24, 2015 at 07:47 GMT

---

@MarcelGerber Only if you edit them, which presumably is pretty unlikely. I don't think anyone's looked at the performance hit of scanning larger lengths, but it would be easy to bump up the cutoff if needed.

Shouldn't be a factor here though: most shell scripts start with a short #! line, and the error message in the original bug report seems to support that.