I've created a bash script but when I try to execute it, I get

#!/bin/bash no such file or directory

I need to run the command: bash script.sh for it to work.

How can I fix this?

  • I have this issue now under cygwin with a script I could swear was already running without problems. I checked all answers, but none seems to fit. Other questions and answers also mentioned 32/64 bit issues, but for shell scripts this could be excluded, right?
    – jan
    Commented Jun 18, 2018 at 8:18
  • Found the reason, added details in new anwer unix.stackexchange.com/a/450389/62636 in case somebody has also used #!/usr/bin/env bash instead of #!/bin/bash and also looking here...
    – jan
    Commented Jun 18, 2018 at 8:33

8 Answers 8


This kind of message is usually due to a buggy shebang line, either an extra carriage return at the end of the first line or a BOM at the beginning of it.


$ head -1 yourscript | od -c

and see how it ends.

This is wrong:

0000000   #   !   /   b   i   n   /   b   a   s   h  \r  \n

This is wrong too:

0000000 357 273 277   #   !   /   b   i   n   /   b   a   s   h  \n

This is correct:

0000000   #   !   /   b   i   n   /   b   a   s   h  \n

Use dos2unix (or sed, tr, awk, perl, python…) to fix your script if this is the issue.

Here is one that will remove both of a BOM and tailing CRs:

sed -i '1s/^.*#//;s/\r$//' brokenScript

Note that the shell you are using to run the script will slightly affect the error messages that are displayed.

Here are three scripts just showing their name (echo $0) and having the following respective shebang lines:


0000000   #   !   /   b   i   n   /   b   a   s   h  \n


0000000 357 273 277   #   !   /   b   i   n   /   b   a   s   h  \n


0000000   #   !   /   b   i   n   /   b   a   s   h  \r  \n

Under bash, running them will show these messages:

$ ./correctScript
$ ./scriptWithCRLF
bash: ./scriptWithCRLF: /bin/bash^M: bad interpreter: No such file or directory
$ ./scriptWithBom
./scriptWithBom: line 1: #!/bin/bash: No such file or directory

Running the buggy ones by explicitely calling the interpreter allows the CRLF script to run without any issue:

$ bash ./scriptWithCRLF
$ bash ./scriptWithBom
./scriptWithBom: line 1: #!/bin/bash: No such file or directory

Here is the behavior observed under ksh:

$ ./scriptWithCRLF
ksh: ./scriptWithCRLF: not found [No such file or directory]
$ ./scriptWithBom
./scriptWithBom[1]: #!/bin/bash: not found [No such file or directory]

and under dash:

$ ./scriptWithCRLF
dash: 2: ./scriptWithCRLF: not found
$ ./scriptWithBom
./scriptWithBom: 1: ./scriptWithBom: #!/bin/bash: not found
  • 3
    Another way of revealing if this is the problem is hexdump -C yourscript | head -n 1. I would still use dos2unix yourscript to fix it.
    – Kevin M
    Commented Dec 17, 2011 at 23:32
  • 2
    If it were a CRLF problem, you wouldn't see a #!/bin/bash no such file or directory error message, as there's no reason anything would try to execute or open #!/bin/bash. It's /bin/bash<CR> what would be executed. Commented Jan 18, 2014 at 8:47
  • 1
    @StephaneChazelas As dos2unix fixed the problem, there is little doubt it wasn't a CRLF problem. The error message was probably just inaccurately transcripted..
    – jlliagre
    Commented Jan 18, 2014 at 18:28
  • 6
    dos2unix also removes an UTF-8 BOM. A UTF-8 BOM could have explained the error message. Commented Jan 18, 2014 at 19:49
  • 1
    It is sad how incompatible Microsoft is. Even with something as basic as ASCII. Commented Jun 18, 2018 at 9:02

This can also be caused by a BOM in a UTF-8 script. If you create the script in Windows sometimes you get some junk at the start of the file.


Actualy, the right shebang for bash script is this:

#!/usr/bin/env bash

Because, in freeBSD, bash is located in /usr/local/bin/bash

  • 14
    "right" is a difficult word to use in such cases. Perhaps a better phrase would be "less error-prone".
    – HalosGhost
    Commented Jun 27, 2014 at 20:56
  • 3
    This is terrible too; the assumption that /usr exists is a bad one IMO. Haiku, for instance, does not have /usr.
    – jessicah
    Commented Jul 5, 2016 at 21:48
  • @jessicah: /usr (as well as /usr/bin/env) are mandatory paths in a POSIX system, be it Linux, FreeBSD or even MacOS. Haiku is not a *nix system, is a cloud computing platform, so you cannot assume any path or tool.
    – MestreLion
    Commented May 14, 2022 at 9:42
  • Great... This worked for me in CentOS 7 Commented Jan 12, 2023 at 21:38
  • the same error could also appear if the sharp symbol # was missed/omitted in the line, i.e. !/bin/bash
    – rellampec
    Commented Apr 4 at 12:40

You can use vi to fix both problems if they exist:

vi <your_file>
:set ff=unix
:set nobomb
  • Answers should be self-contained as much as possible.  The question doesn’t mention two problems; if you’re going to build on other answers, you should at least say what they are.  Better yet, you should explain how this answers the question. Commented May 31, 2017 at 20:42
  • Very quick fix without downloading more windows tools, thanks! Commented Aug 16, 2017 at 21:00
  • 2
    @G-Man Other answers already mention this in much better detail than I wish to go into. No need to repeat, but if it's not painfully obvious, you can have a WIndows line ending and a hidden Windows BOM character. I think a lot of people that are scanning answers appreciate brevity instead of being self contained, especially when there is much more detail in other answers.
    – cwash
    Commented Aug 18, 2017 at 0:27

If you don't have dos2unix this is a way to fix this issue.

cp script _p4 && tr -d '\r' < _p4 > script && rm _p4

Byte-order Mark (BOM)

This could be caused by a BOM. From Wikipedia, a BOM is a

The byte order mark (BOM) is a Unicode character, U+FEFF byte order mark (BOM), whose appearance as a magic number at the start of a text stream can signal several things to a program consuming the text

Unfortunately, it doesn't signal anything to the Linux kernel that handles the she-bang line. You can verify you have a BOM by using file,

file /tmp/foo 
/tmp/foo: UTF-8 Unicode (with BOM) text

Or you can hexdump the first few characters and see if they match any of the BOM characters manually

You can strip the BOM characters once you know them like this,

sed -i '1 s/^\xef\xbb\xbf//' *.txt
  • Works great! And I can confirm that you *only need to remove the BOM once. After I removed it, I could continue to edit the file in Visual Studio and the BOM did not reappear. Thanks! Commented Nov 21, 2022 at 22:01

I had the issue by accidentally adding a wrong bash executable to the PATH and because in my script the more flexible #!/usr/bin/env bash shebang was used (take first bash executable from path).

command -v bash
/cygdrive/c/Program Files/Git/bin//bash

I have installed GIT for Windows to work in cygwin together with Windows GIT GUIs (was not working with cygwin native git...). I solved this now by switching to #!/bin/bash sheband and removing GIT for windows from PATH.


Try #!/bin/bash

Second thing: find / -name bash
Third thing: ls -al /bin/bash

  • 1
    Or just which bash. We know it's finding one because it's working with bash script.sh.
    – Kevin
    Commented Dec 18, 2011 at 2:58
  • True. And as mentioned, there is the much more portable /usr/bin/env method to have a program locate bash (or an other interpreter) for you. No need to hardcode a pah.
    – Hennes
    Commented Jul 17, 2014 at 17:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .