Stworzyłem skrypt bash, ale kiedy próbuję go wykonać, dostaję

#!/bin/bash no such file or directory

Muszę uruchomić polecenie: bash script.shaby zadziałało.

Jak mogę to naprawić?

Ten rodzaj wiadomości zwykle wynika z fałszywej linii shebang, albo dodatkowego powrotu karetki na końcu pierwszej linii, albo BOM na jej początku.

Biegać:

$ head -1 yourscript | od -c

i zobacz jak to się skończy.

To jest źle:

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

To też jest złe:

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

To jest poprawne:

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

Użyj dos2unix(lub sed, tr, awk, perl, python...), aby naprawić swój skrypt, czy jest to problem.

Oto jeden, który usunie zarówno BOM, jak i tailing CR:

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

Oto trzy skrypty pokazujące tylko swoją nazwę ( echo $0) i posiadające następujące odpowiednie linie shebang:

poprawny skrypt:

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

Uruchomienie ich w ramach bash spowoduje wyświetlenie następujących komunikatów:

$ ./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

Uruchamianie fałszywych przez jawne wywołanie interpretera pozwala na uruchomienie skryptu CRLF bez żadnych problemów:

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

Oto zachowanie zaobserwowane w ksh:

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

i poniżej dash:

$ ./scriptWithCRLF
dash: 2: ./scriptWithCRLF: not found
$ ./scriptWithBom
./scriptWithBom: 1: ./scriptWithBom: #!/bin/bash: not found
./scriptWithBom

Może to być również spowodowane przez BOM w skrypcie UTF-8. Jeśli tworzysz skrypt w systemie Windows, czasami na początku pliku pojawia się śmieci.

Właściwie właściwy shebang dla skryptu bash jest następujący:

#!/usr/bin/env bash

Ponieważ w FreeBSD bash znajduje się w /usr/local/bin/bash

Możesz użyć vi, aby naprawić oba problemy, jeśli istnieją:

vi <your_file>
:set ff=unix
:set nobomb
:wq

Jeśli nie masz dos2unix, jest to sposób na rozwiązanie tego problemu.

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

Znak kolejności bajtów (BOM)

Może to być spowodowane przez BOM. Z Wikipedii BOM to

Znak kolejności bajtów (BOM) to znak Unicode, znak kolejności bajtów U + FEFF (BOM), którego pojawienie się jako magicznej liczby na początku strumienia tekstowego może sygnalizować kilka rzeczy programowi używającemu tekstu

Niestety, nic nie sygnalizuje jądru Linuksa, który obsługuje linię she-bang. Możesz sprawdzić, czy masz BOM, używając file,

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

Możesz też zrzucić hex pierwszych kilka znaków i sprawdzić, czy pasują one do któregokolwiek ze znaków BOM ręcznie

Możesz rozebrać znaki BOM, gdy już je znasz,

sed -i '1 s/^\xef\xbb\xbf//' *.txt

Miałem problem przez przypadkowe dodanie niewłaściwego pliku wykonywalnego bash do PATHi ponieważ w moim skrypcie zastosowano bardziej elastyczny #!/usr/bin/env bashshebang (pobierz pierwszy plik wykonywalny bash ze ścieżki).

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

Zainstalowałem GIT dla Windows, aby współpracował cygwinz GUI Windows GIT (nie działał z natywnym gitem Cygwina ...). Rozwiązałem to teraz, przechodząc na #!/bin/bashsheband i usuwając GIT dla Windows z PATH.

Próbować #!/bin/bash

Druga rzecz: find / -name bash
trzecia rzecz:ls -al /bin/bash