-1

I have been having line endings issues on bash scripts for several months. I have another, slightly older Macbook Pro which can run the same scripts without issue.

This has been happening for numerous scripts with different contents written by different people, in different folders. It has affected every script I have attempted to run for the past three months. They have come from Github repos that contain mostly Drupal projects that I've collaborated on with a variety of other developers, none of whom experienced this problem and who were unable to reproduce it with their versions of the scripts. I did not download them as zipped files. I always clone them. They are private repos that I can't link here.

I thought maybe it was related to my .bash_profile settings so I tried changing them to match those of my other machine, which didn't have any effect. I then tried removing all .bash_profile and .bashrc files completely (after backing them up). Again, no effect.

This question is not about how to change line endings, which is covered in similar questions. It is about how to figure out why all the line endings on scripts on my machine are different to those on my other machine and all my coworkers' machines.

This is a systemic problem affecting my whole computer and I'm looking for a a solution more permanent than editing an individual script. The bash version is GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12).

Community
  • 1
  • 1
beth
  • 1,916
  • 4
  • 23
  • 39
  • 1
    "This is not caused by the line endings of the bash scripts I'm trying to run, I've already checked those." Why not? Have you removed the `^M` from a script and then try to run it? Or run it like `bash ./[scriptname]`. –  Sep 29 '14 at 16:05
  • 1
    The error hints you have a ^M at the end of the shebang line. This usually happens when saving the script on MSWin or pre-OS X Mac, or when FTP-ing the scripts with some of the systems involved. – choroba Sep 29 '14 at 16:06
  • When I mentioned having already checked them, I mean that I have tried debugging that way and it has not been effective. – beth Sep 29 '14 at 16:07
  • I would suggest finding out the bash version on your older osx and current then looking up any issues related to version since it works on older.. here are some other links related to same issue http://stackoverflow.com/questions/23097528/bin-shm-bad-interpreter-no-such-file-or-directory http://stackoverflow.com/questions/23097528/bin-shm-bad-interpreter-no-such-file-or-directory http://stackoverflow.com/questions/2920416/configure-bin-shm-bad-interpreter – V H Sep 29 '14 at 16:12
  • I will look up the bash version. I have already read those other questions before posting this one. I believe this one is different because it is a systemic problem, not just with one script. – beth Sep 29 '14 at 16:13
  • 1
    That's not very specific. What does `head -n 1 script_name | cat -v` print? – Keith Thompson Sep 29 '14 at 16:13
  • 1
    Maybe you could explain exactly how you investigated whether the files have `^M`s in them, and how you concluded it's not an issue. – Kenster Sep 29 '14 at 16:14
  • @Kenster Updated with links to what I've tried. – beth Sep 29 '14 at 16:17
  • @KeithThompson It outputs `#!/bin/bash^M`. To be clear, I'm not saying that my issue is not related to line endings, I'm just saying that changing individual line endings doesn't solve the systemic issue because it's not practical to do this to every script on my system, and they run fine for others, and on my other machine. – beth Sep 29 '14 at 16:19
  • I take it back, it looks like my version of dos2unix was broken and that's why it wasn't working. – beth Sep 29 '14 at 16:21
  • So you're confirming that the files have `^M`s in them? On the computers where the scripts work correctly, do they have `^M` in them there? Maybe the problem is with how the files are being copied onto this particular computer. – Kenster Sep 29 '14 at 16:21
  • @Kenster yes, that seems likely. That is what I'm hoping for help figuring out. – beth Sep 29 '14 at 16:22
  • You've just verified that the line ending on at least one falling script is incorrect. That's the problem, and you need to fix it. You previously said you had already checked that. Where did this scripts come from? You say it affects every script on your system; have you really tried *every script on your system*, or have you tried a few and jumped to conclusions? – Keith Thompson Sep 29 '14 at 16:23
  • @KeithThompson it has affected every script I have attempted to run for the past three months. They have come from Github repos that contain mostly Drupal projects that I've collaborated on with a variety of other developers, none of whom experienced this problem and who were unable to reproduce it with their versions of the scripts. – beth Sep 29 '14 at 16:25
  • We *know* what's causing the problem: the scripts you're running have incorrect line endings. Please update your question to indicate *exactly* how you copied those scripts to your machine; that's where the problem is. Did you clone the repo(s)? Which one(s)? Did you use the "Download ZIP" link that appears on each GitHub project page? If so, how *exactly* did you unpack the zip file? Does the problem affect any scripts not downloaded from GitHub? Any UNIX-like system will have a plethora of preinstalled shell scripts; if they *all* were affected, your system probably wouldn't even boot. – Keith Thompson Sep 29 '14 at 17:18
  • How was your `dos2unix` broken? – Keith Thompson Sep 29 '14 at 17:19
  • @KeithThompson question updated. I don't know exactly what was wrong with dos2unix, I thought it was working but after I reinstalled it just to be sure, it started giving me success messages instead of just being silent when I used it. – beth Sep 29 '14 at 17:56
  • Check your `$HOME/.gitconfig`. And see if you can reproduce the problem with some *public* git repo. – Keith Thompson Sep 29 '14 at 18:02
  • "*This is a systemic problem affecting my whole computer*" -- I seriously doubt it. I suggest you either confirm that that's actually true, or update your question to clarify that (if I understand this correctly) the problem only affects scripts you've cloned from GitHub. – Keith Thompson Sep 29 '14 at 18:08

2 Answers2

2

Quick summary: You have core.autocrlf = true in your git configuration.

I've created a small public repo that you should be able to use to reproduce the problem:

git clone git@github.com:Keith-S-Thompson/hello.bash.git

This repo contains a 2-line shell script that should simply print hello on standard output. I expect that when you try it, it will print

bash: ./hello.bash: /bin/bash^M: bad interpreter: No such file or directory

on stderr.

I ran the following command to produce this symptom:

git config --local --add core.autocrlf true

I used --local so it would affect only my local copy of this repo, but you probably have something like:

[core]
        autocrlf = true

in your $HOME/.gitconfig file (or it might be some related option).

You can also use

git config --list

to list your current configuration, including both local and global settings.

Remove the autocrlf = true line. (You can also update your configuration using the git config command; run git config --help for details.) Once you've verified that it fixes the problem for the hello.bash repo, re-clone your other repos.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • It was all exactly as you said here! I have no idea how I ended up with autocrlf = true in my core git settings file. Thank you, this has been bugging me for months! – beth Sep 29 '14 at 19:51
0

Change the new line char. On a normal *nix box you fix this with dos2unix but, according to Google, on osx you need to do:

cat scriptname | col -b > scriptname2
isalgueiro
  • 1,973
  • 16
  • 20
  • The `bad interpreter` error states that bash didn't find what you put in the shebang, and that `^M` thing is not a valid new line on your system, bash is searching for `/bin/bash^M`, not for `/bin/bash` – isalgueiro Sep 29 '14 at 16:09
  • Yes but it is doing that on all scripts, even after converting line endings. I believe you that it is a line ending error but the script is not the root of the problem. The problem is somewhere else. – beth Sep 29 '14 at 16:11