Tento druh zprávy je obvykle způsoben falešná linie shebang, buď zvláštní návrat vozíku na konci jedle první řádek nebo kusovník na jeho začátku.

Spusťte:

$ head -1 yourscript | od -c 

a podívejte se, jak to skončí.

To je špatně:

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

To je také špatně:

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

To je správné:

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

Použijte dos2unix (nebo sed, tr, awk, perl, …) pokud jde o problém, opravte svůj skript.

Zde je jeden, který odstraní jak kusovník, tak i koncový CR:

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

Všimněte si, že prostředí, které používáte ke spuštění skriptu, mírně ovlivní zobrazené chybové zprávy.

Zde jsou tři skripty, které pouze zobrazují jejich název (echo $0) a následující příslušné řádky shebang:

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 

V rámci bash jejich spuštění zobrazí tyto zprávy:

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

Spuštění bo gus ones výslovným voláním tlumočníka umožňuje spuštění skriptu CRLF bez problémů:

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

Zde je chování pozorované pod ksh:

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

a pod dash:

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

Komentáře

• Další způsob, jak odhalit, zda se jedná o problém, je hexdump -C yourscript | head -n 1. K opravě bych stále používal dos2unix yourscript.
• Pokud by se jednalo o problém CRLF, ‚ neuvidíte a #!/bin/bash no such file or directory chybová zpráva, protože ‚ není důvod, aby se něco pokusilo spustit nebo otevřít #!/bin/bash. To ‚ s /bin/bash<CR> co by bylo provedeno.
• @StephaneChazelas Jak dos2unix problém vyřešil, není pochyb nebyl to ‚ ta problém CRLF. Chybová zpráva byla pravděpodobně jen nepřesně přepsána.
• dos2unix také odstraní kusovník UTF-8. Kusovník UTF-8 mohl vysvětlit chybovou zprávu.
• Je smutné, jak nekompatibilní je Microsoft. I při něčem tak základním, jako je ASCII.

To může být způsobeno také kusovníkem v UTF -8 skript. Pokud skript vytvoříte v systému Windows, někdy se vám na začátku souboru stane něco nevyžádaného.

Komentáře

• Kusovník lze snadno odstranit pomocí awk, jako v stackoverflow.com/questions/1068650/…
• Všimněte si, že Visual Studio pro Mac vloží kusovník.

Správný shebang pro bash skript je ve skutečnosti tento:

#!/usr/bin/env bash 

Protože ve freeBSD je bash umístěn v /usr/local/bin/bash

komentářích

• “ vpravo “ je v takových případech obtížné slovo. Možná by lepší fráze byla “ méně náchylná k chybám „.
• To je také hrozné; předpoklad, že / usr existuje, je špatný IMO. Například Haiku nemá / usr.

Oba problémy můžete vyřešit pomocí vi. pokud existují:

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

Komentáře

• Odpovědi by měly být co nejvíce samostatné. Otázka nezmiňuje dva problémy; pokud se chystáte stavět na dalších odpovědích, měli byste alespoň říci, jaké jsou. Ještě lépe, měli byste vysvětlit, jak to odpovídá na otázku.
• Velmi rychlá oprava bez stažení dalších nástrojů systému Windows, díky!
• @ G-Man Další odpovědi už to zmíním mnohem podrobněji, než do čeho bych chtěl jít.Není třeba opakovat, ale pokud to ‚ není bolestně zřejmé, můžete mít konec řádku WIndows a skrytý znak Windows BOM. Myslím, že mnoho lidí, kteří skenují odpovědi, ocení stručnost, místo aby byli samostatní, zvláště když je v dalších odpovědích mnohem více podrobností.

Pokud nemáte dos2unix, můžete tento problém vyřešit.

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

Značka podle pořadí (BOM)

Může to být způsobeno kusovníku. Z Wikipedie je kusovníkem

Značka pořadí bajtů (BOM) je znak Unicode, značka pořadí bajtů U + FEFF (BOM) , jehož vzhled jako magického čísla na začátku textového streamu může signalizovat několik věcí programu spotřebovávajícímu text

Bohužel neregistruje nic do linuxového jádra, které zpracovává linku she-bang. Můžete ověřit, že máte kusovník, pomocí file ,

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

Nebo můžete hexdump prvních pár znaků a uvidíte , zda se shodují s některými znaky kusovníku ručně

Postavy kusovníku můžete odstranit, jakmile je budete takto znát ,

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

Problém jsem měl náhodným přidáním nesprávného bash spustitelný do PATH a protože v mém skriptu byl použit flexibilnější #!/usr/bin/env bash shebang (vezměte si první bash spustitelný soubor z cesty).

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

Nainstaloval jsem GIT pro Windows, aby fungoval v cygwin společně s Windows GIT GUI (nepracoval s nativním gitem cygwin …). Nyní jsem to vyřešil přepnutím na #!/bin/bash sheband a odstraněním GIT pro Windows z PATH.

Zkuste #!/bin/bash

Druhá věc: find / -name bash
Třetí věc: ls -al /bin/bash

Komentáře

• Nebo jen which bash. Známe ‚ s nalezením, protože ‚ pracuje s bash script.sh.
• Pravda. A jak již bylo zmíněno, existuje mnohem přenositelnější metoda / usr / bin / env, která vám umožní vyhledat program bash (nebo jiného tlumočníka). Není třeba pevně kódovat pah.