Diese Art von Nachricht ist normalerweise auf zurückzuführen eine gefälschte Shebang-Linie, entweder ein zusätzlicher Wagenrücklauf am Ende der Tanne st Zeile oder eine Stückliste am Anfang.

Führen Sie Folgendes aus:

$ head -1 yourscript | od -c 

und sehen Sie, wie es endet.

Dies ist falsch:

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

Dies ist auch falsch:

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

Dies ist richtig:

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

Verwenden Sie dos2unix (oder sed, tr, awk, perl, python …), um Ihr Skript zu reparieren, wenn dies das Problem ist.

Hier ist eines, das sowohl eine Stückliste als auch End-CRs entfernt:

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

Beachten Sie, dass die Shell, mit der Sie das Skript ausführen, die angezeigten Fehlermeldungen geringfügig beeinflusst.

Hier sind drei Skripte, die nur ihren Namen anzeigen (echo $0) und mit den folgenden entsprechenden Shebang-Zeilen:

korrektes Skript:

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 

Unter bash werden beim Ausführen folgende Meldungen angezeigt:

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

Bo ausführen Wenn Sie den Interpreter explizit aufrufen, kann das CRLF-Skript problemlos ausgeführt werden:

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

Hier ist das unter ksh:

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

und unter dash:

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

Kommentare

• Eine andere Möglichkeit, festzustellen, ob dies das Problem ist, ist hexdump -C yourscript | head -n 1. Ich würde immer noch dos2unix yourscript verwenden, um das Problem zu beheben.
• Wenn es sich um ein CRLF-Problem handeln würde, würden Sie ‚ nicht sehen Eine #!/bin/bash no such file or directory -Fehlermeldung, da es ‚ keinen Grund gibt, irgendetwas zu versuchen, #!/bin/bash. Es ist ‚ /bin/bash<CR>, was ausgeführt werden würde.
• @StephaneChazelas Da dos2unix das Problem behoben hat, gibt es wenig Zweifel Es war kein ‚ ta CRLF-Problem. Die Fehlermeldung wurde wahrscheinlich nur ungenau transkribiert.
• dos2unix entfernt auch eine UTF-8-Stückliste. Eine UTF-8-Stückliste hätte die Fehlermeldung erklären können.
• Es ist traurig, wie inkompatibel Microsoft ist. Selbst mit etwas so Grundlegendem wie ASCII.

Dies kann auch durch eine Stückliste in einer UTF verursacht werden -8 Skript. Wenn Sie das Skript in Windows erstellen, wird am Anfang der Datei manchmal Junk angezeigt.

Kommentare

• Stückliste kann einfach mit awk entfernt werden. wie in stackoverflow.com/questions/1068650/…
• Beachten Sie, dass Visual Studio für Der Mac fügt eine Stückliste ein.

Tatsächlich lautet der richtige Hinweis für das Bash-Skript:

#!/usr/bin/env bash 

Da sich bash in freeBSD in /usr/local/bin/bash

Kommentare

befindet

• “ rechts “ ist in solchen Fällen ein schwieriges Wort. Vielleicht wäre eine bessere Formulierung “ weniger fehleranfällig „.
• Das ist auch schrecklich; Die Annahme, dass / usr existiert, ist eine schlechte IMO. Haiku hat zum Beispiel nicht / usr.

Sie können vi verwenden, um beide Probleme zu beheben falls vorhanden:

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

Kommentare

• Die Antworten sollten so weit wie möglich in sich geschlossen sein. In der Frage werden zwei Probleme nicht erwähnt. Wenn Sie auf anderen Antworten aufbauen möchten, sollten Sie mindestens sagen, was sie sind. Besser noch, Sie sollten erklären, wie dies die Frage beantwortet.
• Sehr schnelle Lösung, ohne weitere Windows-Tools herunterzuladen, danke!
• @ G-Man Andere Antworten Erwähne dies bereits viel ausführlicher, als ich darauf eingehen möchte.Keine Notwendigkeit zu wiederholen, aber wenn es ‚ nicht schmerzlich offensichtlich ist, können Sie ein Windows-Zeilenende und ein verstecktes Windows-Stücklistenzeichen haben. Ich denke, viele Leute, die Antworten scannen, schätzen die Kürze, anstatt in sich geschlossen zu sein, insbesondere wenn andere Antworten viel detaillierter sind.

Wenn Sie nicht über dos2unix verfügen, können Sie dieses Problem auf diese Weise beheben.

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

Byte-Order Mark (BOM)

Dies kann verursacht werden durch eine Stückliste. Aus Wikipedia ist eine Stückliste eine

Die Byte-Ordnungsmarke (BOM) ist ein Unicode-Zeichen, U + FEFF-Byte-Ordnungsmarke (BOM) , dessen Erscheinen als magische Zahl am Anfang eines Textstroms einem Programm, das den Text verbraucht, mehrere Dinge signalisieren kann

Leider signalisiert dem Linux-Kernel, der die She-Bang-Zeile verarbeitet, nichts. Sie können überprüfen, ob Sie eine Stückliste haben, indem Sie file verwenden ,

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

Oder Sie können hexdump die ersten paar Zeichen und sehen Sie , ob sie manuell mit einem der Stücklistenzeichen übereinstimmen

Sie können die Stücklistenzeichen entfernen, sobald Sie sie so kennen ,

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

Ich hatte das Problem, indem ich versehentlich eine falsche Bash hinzugefügt habe ausführbar für die PATH und weil in meinem Skript die flexiblere #!/usr/bin/env bash shebang verwendet wurde (nehmen Sie die erste ausführbare Bash-Datei vom Pfad).

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

Ich habe GIT für Windows installiert, damit es in cygwin zusammen mit Windows GIT-GUIs funktioniert (funktionierte nicht mit cygwin native git …). Ich habe dies jetzt gelöst, indem ich zu #!/bin/bash sheband gewechselt und GIT für Windows aus PATH entfernt habe.

Versuchen Sie #!/bin/bash

Zweitens: find / -name bash
Dritte Sache: ls -al /bin/bash

Kommentare

• Oder einfach which bash. Wir wissen, dass ‚ einen findet, weil ‚ mit bash script.sh arbeitet.
• Richtig. Und wie bereits erwähnt, gibt es die viel portablere Methode / usr / bin / env, mit der ein Programm Bash (oder einen anderen Interpreter) für Sie lokalisiert. Es ist nicht erforderlich, einen Pah fest zu codieren.