#!/bin/bash - no such file or directory
Solution 1
This kind of message is usually due to a bogus shebang line, either an extra carriage return at the end of the first line or a BOM at the beginning of it.
Run:
$ 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:
correctScript:
0000000 # ! / b i n / b a s h \n
scriptWithBom:
0000000 357 273 277 # ! / b i n / b a s h \n
scriptWithCRLF:
0000000 # ! / b i n / b a s h \r \n
Under bash, running them will show these messages:
$ ./correctScript
./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
./scriptWithBom
Running the bogus ones by explicitely calling the interpreter allows the CRLF script to run without any issue:
$ bash ./scriptWithCRLF
./scriptWithCRLF
$ bash ./scriptWithBom
./scriptWithBom: line 1: #!/bin/bash: No such file or directory
./scriptWithBom
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]
./scriptWithBom
and under dash
:
$ ./scriptWithCRLF
dash: 2: ./scriptWithCRLF: not found
$ ./scriptWithBom
./scriptWithBom: 1: ./scriptWithBom: #!/bin/bash: not found
./scriptWithBom
Solution 2
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.
Solution 3
Actualy, the right shebang for bash script is this:
#!/usr/bin/env bash
Because, in freeBSD, bash is located in /usr/local/bin/bash
Solution 4
You can use vi to fix both problems if they exist:
vi <your_file>
:set ff=unix
:set nobomb
:wq
Solution 5
If you don't have dos2unix this is a way to fix this issue.
cp script _p4 && tr -d '\r' < _p4 > script && rm _p4
NJanf
Updated on September 18, 2022Comments
-
NJanf over 1 year
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?
-
jan almost 6 yearsI 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 almost 6 yearsFound 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...
-
-
mm2001 over 12 yearsAnother way of revealing if this is the problem is
hexdump -C yourscript | head -n 1
. I would still usedos2unix yourscript
to fix it. -
NJanf over 12 yearsYes it could very well be that. I edited in on windows. Things for the tip.
-
Kevin over 12 yearsOr just
which bash
. We know it's finding one because it's working withbash script.sh
. -
Stéphane Chazelas over 10 yearsIf 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. -
jlliagre over 10 years@StephaneChazelas As dos2unix fixed the problem, there is little doubt it wasn't a CRLF problem. The error message was probably just inaccurately transcripted..
-
Stéphane Chazelas over 10 years
dos2unix
also removes an UTF-8 BOM. A UTF-8 BOM could have explained the error message. -
jlliagre over 10 years@StephaneChazelas I agree the error message would have included the shebang but the OP complains that the script was not executed when called as is, but correctly run when passed as a bash argument. With an UTF-8 BOM, the script would have been executed in both cases, not just the second one, and the error message would have been displayed in both cases too, which isn't what the OP is describing.
-
Jakob Bennemann almost 10 years"right" is a difficult word to use in such cases. Perhaps a better phrase would be "less error-prone".
-
Jpark822 almost 10 yearsTrue. 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.
-
pauxu over 9 yearsBOM can be removed easily using awk, as in stackoverflow.com/questions/1068650/…
-
jessicah almost 8 yearsThis is terrible too; the assumption that /usr exists is a bad one IMO. Haiku, for instance, does not have /usr.
-
G-Man Says 'Reinstate Monica' almost 7 yearsAnswers 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.
-
steampowered over 6 yearsVery quick fix without downloading more windows tools, thanks!
-
cwash over 6 years@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.
-
ctrl-alt-delor almost 6 yearsIt is sad how incompatible Microsoft is. Even with something as basic as ASCII.
-
jlliagre almost 6 years@ctrl-alt-delor Yes. Note that Mac OS used to be ending its lines with a third alternative but is now aligned with Unix/Linux. See unix.stackexchange.com/questions/411811/…
-
ctrl-alt-delor almost 6 years@jlliagre I was commenting about adding a BOM, to the start of the file (it is not even part of UTF-8, and they add it to the start of an ASCII file as well). However you are correct, they do line endings differently as well, making their text files 2%→5% bigger, and incompatible.
-
Clearer over 5 years@jlliagre On current macOS a BOM will screw everything up.
-
Clearer over 5 yearsNote that Visual Studio for Mac will insert a BOM.
-
jlliagre over 5 years@Clearer On older too. AFAIK a BOM screws everything up whatever the OS.
-
Admin almost 2 years@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.