-2

All of the bash commands I've written for my Mac (10.11 El Capitan) work great, yet they throw an error when they are done running. So, for instance, if I do this: 

cat /usr/local/bin/en-deploy

You can see I wrote this script:

#Bash
#!/bin/sh
curl ec2-14-43-7-17.compute-1.amazonaws.com:10000 -d $1;

This script works great, but when I call it, I get: 

Your branch is up-to-date with 'origin/master'.
: command not foundeploy: line 3:

The first line is the expected output. The second line is just weird. What do I need to do to get rid of it?

UPDATE:

If I edit the file to: 

  #!/bin/bash
  curl ec2-54-173-70-97.compute-1.amazonaws.com:30000 -d $1;

I get: 

  -bash: /usr/local/bin/en-deploy: /bin/bash^M: bad interpreter: No such file or directory
lorm
  • 3,141
  • 3
  • 15
  • 20
  • #Bash at the top doesn't make sense. the shebang line (#!) needs to be the first line and should point to what you want to use. on OSX that should be `#!/bin/sh` (which on OSX is bash) – Doon May 17 '16 at 17:58
  • 2
    my guess is that you've created your script in a windows environment. If so, use `dos2unix myScript.sh` to remove troublesome `\r` characters. Good luck. – shellter May 17 '16 at 17:59
  • BTW, if you start a script with `#!/bin/sh`, it's not a bash script, it's a POSIX sh script. Bash scripts need to start with `#!/bin/bash`. – Charles Duffy May 17 '16 at 18:05
  • @CharlesDuffy: Many systems make `/bin/sh` a symlink to `/bin/bash`, so the script *may or may not* be executed by bash.On the other hand, bash enters POSIX mode if it's invoked as `sh`. – Keith Thompson May 17 '16 at 18:15
  • @KeithThompson, even if it's a symlink, the end effect is that the full bash language is unavailable, and that it's not suitable for executing "bash scripts" (as the OP refers to in the question title). – Charles Duffy May 17 '16 at 18:26
  • I agree this looks like Windows newlines, but I wrote this on a Mac. Maybe I copy and pasted something from the web? If I delete the first line Bash, then I get: "-bash: /usr/local/bin/en-deploy: /bin/sh^M: bad interpreter: No such file or directory" – lorm May 17 '16 at 18:51

1 Answers1

4

#!/bin/sh (or #!/bin/bash for Bash) needs to be the first line of your script. And use quotes.

#!/bin/bash
curl 'ec2-14-43-7-17.compute-1.amazonaws.com:10000' -d "$1"

And also run dos2unix script to make sure your script is in UNIX file format. As @shellter has pointed out with comment, it seems that your script is not in UNIX format.

Note: dos2unix script will convert the file in-place.

Jahid
  • 21,542
  • 10
  • 90
  • 108
  • True, but not the cause of the issue here; this is clearly DOS newlines. – Charles Duffy May 17 '16 at 18:05
  • Also, the OP has specifically asked about bash, so pointing to `#!/bin/bash` is probably more correct than `#!/bin/sh`. – Charles Duffy May 17 '16 at 18:05
  • (Re: "a good chance", I can't think of any other cause for the `:command not found` at the front of a line, other than it being a literal `$'\r'` character being run as a command that's not found. Can you?) – Charles Duffy May 17 '16 at 18:07
  • @CharlesDuffy : unquoting `$1` can cause unexpected behavior.. – Jahid May 17 '16 at 18:07
  • ...an unquoted `$1` in that position can expand into any number of parameters, or no parameters at all, but anything and everything it expands into still will be a command-line argument to `curl`, not a new command to generate a "command not found" error. – Charles Duffy May 17 '16 at 18:08
  • @CharlesDuffy : yap, true, It's definitely a dos2unix problem.. – Jahid May 17 '16 at 18:11
  • Be sure to read the man page for `dos2unix` before running it. Unlike most text filter commands, it updates its input file in place. – Keith Thompson May 17 '16 at 18:16
  • @KeithThompson : I don't see your point. There's no risk involved running `dos2unix` on a file that is supposed to be a UNIX text file. If it's already UNIX then good, if not it will convert it to UNIX. – Jahid May 17 '16 at 18:23
  • @Jahid: Most Unix text filters read from stdin or from one or more specified files and write to stdout. If `dos2unix` worked that way, I'd likely do something like `dos2unix file.txt > tmpfile && mv tmpfile file.txt`. But because it modifies its input file rather than writing to stdout, the above command will zero the file. `dos2unix`'s behavior is arguably more convenient. My point is simply that you have to be aware of the difference. – Keith Thompson May 17 '16 at 18:26
  • @KeithThompson : I again fail to see your point. I wrote the command to be run as `dos2unix script`, why would you think otherwise? – Jahid May 17 '16 at 18:30
  • @Jahid: Someone who is familiar with Unix commands but who doesn't happen to know that `dos2unix` behaves differently than 99% of Unix text filters might not assume that `dos2unix script` is the entire command to execute, and that they need to capture its output. (I have to check the man page for `dos2unix` every time I run it, to avoid messing things up.) – Keith Thompson May 17 '16 at 18:32
  • @KeithThompson : ok, but checking the man page everytime is a bit extreme (IMO). I have added a note to clarify that it changes the file in-place. – Jahid May 17 '16 at 18:38
  • See my update. I changed the shebang – lorm May 17 '16 at 18:53
  • The dos2unix script seems to have fixed it!!! Thank you very much!!!!! – lorm May 17 '16 at 18:58