Denna typ av meddelande beror vanligtvis på en falsk shebanglinje, antingen en extra vagnretur i slutet av granen st-rad eller en BOM i början av den.

Kör:

$ head -1 yourscript | od -c 

och se hur det slutar.

Detta är fel:

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

Detta är också fel:

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

Detta är korrekt:

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

Använd dos2unix (eller sed, tr, awk, perl, python …) för att fixa ditt skript om det här är problemet.

Här är en som tar bort både en BOM och CR-avgränsning:

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

Observera att skalet du använder för att köra skriptet påverkar något av de felmeddelanden som visas.

Här är tre skript som bara visar deras namn (echo $0) och har följande respektive shebang-rader:

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 visas följande meddelanden när du kör dem:

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

Kör bo gus ones genom att uttryckligen anropa tolken tillåter CRLF-skriptet att köras utan problem:

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

Här är beteendet som observeras 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 

och under dash:

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

Kommentarer

• Ett annat sätt att avslöja om detta är problemet är hexdump -C yourscript | head -n 1. Jag skulle fortfarande använda dos2unix yourscript för att fixa det.
• Om det var ett CRLF-problem skulle du inte se ’ ett #!/bin/bash no such file or directory felmeddelande, eftersom ’ inte är anledningen till att något skulle försöka utföra eller öppna #!/bin/bash. Det ’ s /bin/bash<CR> vad som skulle köras.
• @StephaneChazelas Eftersom dos2unix fixade problemet finns det ingen tvekan det var inte ’ som ett CRLF-problem. Felmeddelandet transkriberades antagligen bara felaktigt.
• dos2unix tar också bort en UTF-8 BOM. En UTF-8 BOM kunde ha förklarat felmeddelandet.
• Det är sorgligt hur inkompatibelt Microsoft är. Även med något så grundläggande som ASCII.

Detta kan också orsakas av en BOM i en UTF -8-skript. Om du skapar skriptet i Windows får du ibland skräp i början av filen.

Kommentarer

• BOM kan enkelt tas bort med awk, som i stackoverflow.com/questions/1068650/…
• Observera att Visual Studio för Mac infogar en BOM.

Faktiskt, rätt shebang för bash-skript är detta:

#!/usr/bin/env bash 

Eftersom bash i freeBSD ligger i /usr/local/bin/bash

Kommentarer

• ” höger ” är ett svårt ord att använda i sådana fall. Kanske skulle en bättre fras vara ” mindre felbenägen ”.
• Det här är också hemskt; antagandet att / usr existerar är en dålig IMO. Haiku har till exempel inte / usr.

Du kan använda vi för att åtgärda båda problemen om de existerar:

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

Kommentarer

• Svaren bör vara fristående så mycket som möjligt. Frågan nämner inte två problem; om du ska bygga på andra svar bör du åtminstone säga vad de är. Bättre än, du bör förklara hur detta svarar på frågan.
• Mycket snabb fix utan att ladda ner fler Windows-verktyg, tack!
• @ G-Man Andra svar nämner detta redan mycket bättre än jag vill gå in på.Inget behov av att upprepa, men om det ’ inte är smärtsamt uppenbart kan du ha en WIndows-rad som slutar och en dold Windows-BOM-karaktär. Jag tror att många människor som söker efter svar uppskattar korthet istället för att vara fristående, speciellt när det finns mycket mer detaljer i andra svar.

Om du inte har dos2unix är detta ett sätt att lösa problemet.

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

Byte-order Mark (BOM)

Detta kan orsakas av a Stycklista. Från Wikipedia är en Stycklista en

Byteordermärke (BOM) är ett Unicode-tecken, U + FEFF byte ordermark (BOM) , vars utseende som ett magiskt nummer i början av en textström kan signalera flera saker till ett program som konsumerar texten

Tyvärr det signalerar ingenting till Linux-kärnan som hanterar she-bang-linjen. Du kan verifiera att du har en BOM genom att använda file ,

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

Eller så kan du hexdumpa de första tecknen och se om de matchar något av BOM-tecknen manuellt

Du kan ta bort BOM-tecknen när du känner dem så här ,

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

Jag fick problemet genom att av misstag lägga till en fel bash körbar till PATH och för att i mitt skript användes den mer flexibla #!/usr/bin/env bash shebang (ta första bash-körbara från sökvägen).

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

Jag har installerat GIT för Windows för att fungera i cygwin tillsammans med Windows GIT GUI (arbetade inte med cygwin native git …). Jag löste det nu genom att byta till #!/bin/bash sheband och ta bort GIT för windows från PATH.

Försök #!/bin/bash

Andra sak: find / -name bash
Tredje saken: ls -al /bin/bash

Kommentarer

• Eller bara which bash. Vi vet att den ’ hittar en eftersom den ’ arbetar med bash script.sh.
• sant. Och som nämnts finns det den mycket mer bärbara / usr / bin / env-metoden att låta ett program hitta bash (eller en annan tolk) åt dig. Inget behov av att koda en pah.