Tällainen viesti johtuu yleensä väärä shebang-linja, joko ylimääräinen paluupaluu kuusen päässä st line tai BOM sen alussa.

Suorita:

$ head -1 yourscript | od -c 

ja katso kuinka se päättyy.

Tämä on väärä:

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

Myös tämä on väärin:

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

Tämä on oikein:

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

Käytä dos2unix (tai sed, tr, awk, perl, python…) korjata komentosarjasi, jos tämä on ongelma.

Tässä on yksi, joka poistaa sekä BOM: n että hännän CR: t:

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

Huomaa, että komentosarjan suorittamiseen käytetty kuori vaikuttaa hieman näytettäviin virheilmoituksiin.

Tässä on kolme komentosarjaa, jotka vain osoittavat nimensä (echo $0) ja jolla on seuraavat vastaavat shebang-rivit:

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 

Bashissa niiden suorittaminen näyttää seuraavat viestit:

$ ./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: n juokseminen Gus one -kutsumalla tulkki nimenomaisesti, CRLF-komentosarja voidaan suorittaa ilman mitään ongelmia:

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

Tässä on ksh:

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

ja alle dash:

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

Kommentit

• Toinen tapa paljastaa ongelma on hexdump -C yourscript | head -n 1. Käytän silti korjaamaan sen dos2unix yourscript.
• Jos se olisi CRLF-ongelma, et näe ’ #!/bin/bash no such file or directory -virhesanoma, koska ’ ei ole mitään syytä yrittää suorittaa tai avata #!/bin/bash. Se ’ s /bin/bash<CR> mitä suoritetaan.
• @StephaneChazelas Koska dos2unix korjasi ongelman, ei ole epäilystäkään se ei ollut ’ ta CRLF-ongelma. Virhesanoma oli todennäköisesti vain virheellisesti transkriptoitu.
• dos2unix poistaa myös UTF-8: n BOM: n. UTF-8 BOM olisi voinut selittää virhesanoman.
• On surullista, kuinka yhteensopimaton Microsoft on. Jopa jotain niin yksinkertaista kuin ASCII.

Tämän voi aiheuttaa myös UTF: n BOM. -8 käsikirjoitus. Jos luot komentosarjan Windowsissa, saat joskus roskaa tiedoston alusta.

Kommentit

• BOM voidaan poistaa helposti awk: llä, kuten stackoverflow.com/questions/1068650/…
• Huomaa, että Visual Studio for Mac lisää luettelon.

Oikeastaan bash-komentosarjan oikea shebang on tämä:

#!/usr/bin/env bash 

Koska FreeBSD: ssä bash sijaitsee /usr/local/bin/bash

kommenteissa

• ” right ” on vaikea käyttää sellaisissa tapauksissa. Ehkä parempi lause olisi ” vähemmän virhealtista ”.
• Tämä on myös kauheaa; oletus, että / usr on olemassa, on huono IMO. Esimerkiksi Haikulla ei ole / usr-tiedostoa.

Voit korjata molemmat ongelmat vi: llä jos niitä on:

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

kommentit

• vastausten tulisi olla mahdollisimman itsenäisiä. Kysymyksessä ei mainita kahta ongelmaa; jos aiot rakentaa muita vastauksia, sinun tulisi ainakin sanoa, mitä ne ovat. Parempi on, että sinun tulisi selittää, miten tämä vastaa kysymykseen.
• Erittäin nopea korjaus lataamatta lisää Windows-työkaluja, kiitos!
• @ G-Man Muut vastaukset mainitse tämä jo paljon yksityiskohtaisemmin kuin haluaisin mennä.Ei tarvitse toistaa, mutta jos se ’ ei ole tuskallisen ilmeinen, sinulla voi olla WIndows-rivin loppu ja piilotettu Windowsin BOM-merkki. Mielestäni monet ihmiset, jotka etsivät vastauksia, arvostavat lyhyyttä sen sijaan, että olisivat itsenäisiä, varsinkin kun muissa vastauksissa on paljon yksityiskohtaisempaa tietoa.

Jos sinulla ei ole dos2unix-tiedostoa, tämä on tapa korjata ongelma.

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

tavujärjestysmerkki (BOM)

Tämän voi aiheuttaa BOM. Wikipediasta BOM on

Tavujärjestysmerkki (BOM) on Unicode-merkki, U + FEFF-tavujärjestysmerkki (BOM) , jonka esiintyminen maagisena numerona tekstivirran alussa voi merkitä useita asioita tekstiä kuluttavalle ohjelmalle

Valitettavasti se ei osoita mitään Linux-ytimelle, joka käsittelee she-bang-riviä. Voit varmistaa, että sinulla on BOM käyttämällä file ,

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

Tai voit tehdä hexdump ensimmäiset merkit ja katso jos ne vastaavat mitä tahansa BOM-merkkiä manuaalisesti

Voit poistaa BOM-merkit, kun tunnet ne tältä ,

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

Minulla oli ongelma lisäämällä vahingossa väärä bash suoritettava tiedostoon PATH ja koska komentosarjassa käytettiin joustavampaa #!/usr/bin/env bash shebangia (ota ensimmäinen suoritettava bash polulta).

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

Olen asentanut GIT for Windows toimimaan cygwin yhdessä Windows GIT -käyttöliittymien kanssa (ei toiminut alkuperäisen cygwin-gitin kanssa …). Olen ratkaissut tämän nyt siirtymällä #!/bin/bash sheband-kansioon ja poistamalla GIT Windowsille PATH.

Kokeile #!/bin/bash

Toinen asia: find / -name bash
Kolmas asia: ls -al /bin/bash

kommentit

• Tai vain which bash. Tiedämme sen ’ löytävän, koska se ’ työskentelee bash script.sh.
• Totta. Ja kuten mainittiin, on olemassa paljon kannettavampi menetelmä / usr / bin / env, jolla ohjelma etsii bashin (tai muun tulkin) sinulle. Ei tarvitse koodata pahaa.