Denne typen meldinger skyldes vanligvis en falsk shebang-linje, enten en ekstra vognretur på slutten av gran st-linjen eller en BOM i begynnelsen av den.

Kjør:

$ head -1 yourscript | od -c 

og se hvordan den ender.

Dette er feil:

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

Dette er også feil:

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

Dette er riktig:

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

Bruk dos2unix (eller sed, tr, awk, perl, python …) for å fikse skriptet ditt hvis dette er problemet.

Her er en som fjerner både en stykklisten og avgrensende CR-er:

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

Merk at skallet du bruker til å kjøre skriptet, vil påvirke feilmeldingene som vises litt.

Her er tre skript som bare viser navnet deres (echo $0) og har følgende respektive shebang-linjer:

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 vil kjøring av dem vise disse meldingene:

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

Kjører bo gus ones ved eksplisitt å ringe tolken lar CRLF-skriptet kjøre uten problemer:

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

Her er oppførselen som observeres 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 

og under dash:

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

Kommentarer

• En annen måte å avsløre om dette er problemet, er hexdump -C yourscript | head -n 1. Jeg vil fortsatt bruke dos2unix yourscript for å fikse det.
• Hvis det var et CRLF-problem, ville du ikke se ‘ en #!/bin/bash no such file or directory feilmelding, da det ‘ ingen grunn til at noe ville prøve å utføre eller åpne #!/bin/bash. Det ‘ s /bin/bash<CR> hva som ville bli utført.
• @StephaneChazelas Da dos2unix løste problemet, er det liten tvil det var ikke ‘ ta CRLF-problem. Feilmeldingen ble sannsynligvis bare transkriptert unøyaktig ..
• dos2unix fjerner også en UTF-8 BOM. En UTF-8 BOM kunne ha forklart feilmeldingen.
• Det er trist hvor inkompatibel Microsoft er. Selv med noe så grunnleggende som ASCII.

Dette kan også være forårsaket av en BOM i en UTF -8 skript. Hvis du oppretter skriptet i Windows, får du noen ganger søppel i begynnelsen av filen.

Kommentarer

• BOM kan enkelt fjernes ved hjelp av awk, som i stackoverflow.com/questions/1068650/…
• Merk at Visual Studio for Mac vil sette inn en BOM.

Egentlig er riktig shebang for bash-skript dette:

#!/usr/bin/env bash 

Fordi, i freeBSD, ligger bash i /usr/local/bin/bash

Kommentarer

• » høyre » er et vanskelig ord å bruke i slike tilfeller. Kanskje en bedre setning ville være » mindre feilutsatt «.
• Dette er også forferdelig; antagelsen om at / usr eksisterer er en dårlig IMO. Haiku har for eksempel ikke / usr.

Du kan bruke vi til å løse begge problemene hvis de eksisterer:

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

Kommentarer

• Svarene bør være selvstendige så mye som mulig. Spørsmålet nevner ikke to problemer; hvis du skal bygge på andre svar, bør du i det minste si hva de er. Enda bedre, du bør forklare hvordan dette svarer på spørsmålet.
• Veldig rask løsning uten å laste ned flere Windows-verktøy, takk!
• @ G-Man Andre svar nevner dette allerede i mye bedre detaljer enn jeg ønsker å gå inn på.Ingen grunn til å gjenta, men hvis det ‘ ikke er smertefullt opplagt, kan du ha en WIndows-linjeavslutning og en skjult Windows BOM-karakter. Jeg tror mange mennesker som skanner svar, setter pris på korthet i stedet for å være selvforsynt, spesielt når det er mye mer detaljert i andre svar.

Hvis du ikke har dos2unix, er dette en måte å løse dette problemet på.

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

Byte-order Mark (BOM)

Dette kan være forårsaket av en stykliste. Fra Wikipedia er en styklist en

Bytebestillingsmerke (BOM) er et Unicode-tegn, U + FEFF bytebestillingsmerke (BOM) , hvis utseende som et magisk tall i begynnelsen av en tekststrøm kan signalisere flere ting til et program som bruker teksten

Dessverre det signaliserer ikke noe til Linux-kjernen som håndterer she-bang-linjen. Du kan bekrefte at du har en BOM ved å bruke file ,

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

Eller du kan hexdumpe de første få tegnene og se hvis de samsvarer med noen av BOM-tegnene manuelt

Du kan strippe BOM-tegnene når du kjenner dem slik ,

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

Jeg hadde problemet ved å legge til en feil bash ved et uhell kjørbar til PATH og fordi den mer fleksible #!/usr/bin/env bash shebang ble brukt i skriptet mitt (ta første bash-kjørbare fra banen).

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

Jeg har installert GIT for Windows for å fungere i cygwin sammen med Windows GIT GUI (jobbet ikke med cygwin native git …). Jeg løste dette nå ved å bytte til #!/bin/bash sheband og fjerne GIT for windows fra PATH.

Prøv #!/bin/bash

Andre ting: find / -name bash
Tredje ting: ls -al /bin/bash

Kommentarer

• Eller bare which bash. Vi vet at den ‘ finner en fordi den ‘ arbeider med bash script.sh.
• Sant. Og som nevnt er det den mye mer bærbare / usr / bin / env-metoden for å få et program til å finne bash (eller en annen tolk) for deg. Du trenger ikke å kode en pah.