Denne form for besked skyldes normalt en falsk shebang-linje, enten en ekstra vognretur i slutningen af firen st line eller en BOM i begyndelsen af den.

Kør:

$ head -1 yourscript | od -c 

og se, hvordan den ender.

Dette er forkert:

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

Dette er også forkert:

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

Dette er korrekt:

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

Brug dos2unix (eller sed, tr, awk, perl, python …) for at rette dit script, hvis dette er problemet.

Her er en, der fjerner både en stykliste og hale CRer:

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

Bemærk, at den skal, du bruger til at køre scriptet, vil påvirke de viste fejlmeddelelser en smule.

Her er tre scripts, der bare viser deres navn (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 viser disse meddelelser at køre 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ører bo gus ones ved eksplicit at kalde tolken tillader CRLF-scriptet at køre uden noget problem:

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

Her er den adfærd, der 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 anden måde at afsløre, om dette er problemet, er hexdump -C yourscript | head -n 1. Jeg vil stadig bruge dos2unix yourscript til at rette det.
• Hvis det var et CRLF-problem, ville du ikke ‘ ikke se en #!/bin/bash no such file or directory fejlmeddelelse, da der ‘ ingen grund til, at noget ville forsøge at udføre eller åbne #!/bin/bash. Det ‘ s /bin/bash<CR> hvad der ville blive udført.
• @StephaneChazelas Da dos2unix løste problemet, er der kun lidt tvivl det var ikke ‘ et CRLF-problem. Fejlmeddelelsen blev sandsynligvis bare transkriberet unøjagtigt.
• dos2unix fjerner også en UTF-8 BOM. En UTF-8 BOM kunne have forklaret fejlmeddelelsen.
• Det er trist, hvor inkompatibelt Microsoft er. Selv med noget så grundlæggende som ASCII.

Dette kan også være forårsaget af en stykliste i en UTF -8 script. Hvis du opretter scriptet i Windows, får du nogle gange noget skrammel i starten af filen.

Kommentarer

• BOM kan nemt fjernes ved hjælp af awk, som i stackoverflow.com/questions/1068650/…
• Bemærk, at Visual Studio til Mac indsætter en stykliste.

Faktisk er den rigtige shebang til bash-script dette:

#!/usr/bin/env bash 

Fordi bash i freeBSD er placeret i /usr/local/bin/bash

Kommentarer

• ” højre ” er et vanskeligt ord at bruge i sådanne tilfælde. Måske ville en bedre sætning være ” mindre fejlbehæftet “.
• Dette er også forfærdeligt; antagelsen om, at / usr eksisterer, er en dårlig IMO. Haiku har for eksempel ikke / usr.

Du kan bruge vi til at løse begge problemer hvis de findes:

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

Kommentarer

• Svarene skal være selvstændige så meget som muligt. Spørgsmålet nævner ikke to problemer; hvis du vil bygge på andre svar, skal du i det mindste sige hvad de er. Bedre endnu, du skal forklare hvordan dette besvarer spørgsmålet.
• Meget hurtig løsning uden at downloade flere Windows-værktøjer, tak!
• @ G-Man Andre svar nævner allerede dette meget bedre detaljer end jeg ønsker at gå ind på.Ingen grund til at gentage det, men hvis det ‘ ikke er smertefuldt indlysende, kan du have en WIndows-linjeafslutning og en skjult Windows BOM-karakter. Jeg tror, at mange mennesker, der scanner svar, sætter pris på kortfattethed i stedet for at være selvstændigt, især når der er meget mere detaljeret i andre svar.

Hvis du ikke har dos2unix, er dette en måde at løse dette problem på.

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

Byte-order Mark (BOM)

Dette kan skyldes en stykliste. Fra Wikipedia er en stykliste en

Byteordermærket (BOM) er et Unicode-tegn, U + FEFF byteordermærke (BOM) , hvis udseende som et magisk nummer i starten af en tekststrøm kan signalere flere ting til et program, der forbruger teksten

Desværre det signalerer ikke noget til Linux-kernen, der håndterer she-bang-linjen. Du kan bekræfte, at du har en BOM ved hjælp af file ,

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

Eller du kan hexdumpe de første få tegn og se hvis de matcher nogen af BOM-tegnene manuelt

Du kan fjerne BOM-tegnene, når du kender dem sådan ,

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

Jeg fik problemet ved ved et uheld at tilføje en forkert bash eksekverbar til PATH og fordi den mere fleksible #!/usr/bin/env bash shebang i mit script blev brugt (tag den første bash-eksekverbare fra stien).

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

Jeg har installeret GIT til Windows til at arbejde i cygwin sammen med Windows GIT GUIer (arbejdede ikke med cygwin native git …). Jeg løste dette nu ved at skifte til #!/bin/bash sheband og fjerne GIT til windows fra PATH.

Prøv #!/bin/bash

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

Kommentarer

• Eller bare which bash. Vi ved, at den ‘ finder en, fordi den ‘ arbejder med bash script.sh.
• Sandt. Og som nævnt er der den meget mere bærbare / usr / bin / env-metode til at få et program til at finde bash (eller en anden tolk) til dig. Ingen grund til at kode en pah.