Esse tipo de mensagem geralmente se deve a uma linha bogus shebang, ou um retorno de carruagem extra no final do abeto st linha ou um BOM no início dela.

Execute:

$ head -1 yourscript | od -c 

e veja como termina.

Isso está errado:

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

Isso também está errado:

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

Correto:

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

Use dos2unix (ou sed, tr, awk, perl, python…) para corrigir seu script se este for o problema.

Aqui está um que removerá tanto o BOM quanto os CRs de cauda:

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

Observe que o shell que você está usando para executar o script afetará um pouco as mensagens de erro que são exibidas.

Aqui estão três scripts mostrando apenas seus nomes (echo $0) e ter as seguintes linhas de shebang respectivas:

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 

No bash, executá-los mostrará estas mensagens:

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

Executando o bo gus ones ao chamar explicitamente o intérprete permite que o script CRLF seja executado sem nenhum problema:

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

Aqui está o comportamento observado em ksh:

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

e em dash:

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

Comentários

• Outra maneira de revelar se esse é o problema é hexdump -C yourscript | head -n 1. Eu ainda usaria dos2unix yourscript para corrigi-lo.
• Se fosse um problema de CRLF, você ‘ não veria uma #!/bin/bash no such file or directory mensagem de erro, pois não ‘ s nenhum motivo para tentar executar ou abrir #!/bin/bash. É ‘ s /bin/bash<CR> o que seria executado.
• @StephaneChazelas Como dos2unix corrigiu o problema, há pouca dúvida não era ‘ um problema CRLF. A mensagem de erro provavelmente foi apenas transcrita de forma imprecisa.
• dos2unix também remove um BOM UTF-8. Um BOM UTF-8 poderia ter explicado a mensagem de erro.
• É triste como a Microsoft é incompatível. Mesmo com algo tão básico como ASCII.

Isso também pode ser causado por um BOM em um UTF -8 script. Se você criar o script no Windows, às vezes obtém algum lixo no início do arquivo.

Comentários

• BOM pode ser removido facilmente usando awk, como em stackoverflow.com/questions/1068650/…
• Observe que o Visual Studio para O Mac irá inserir um BOM.

Na verdade, o shebang certo para o script bash é este:

#!/usr/bin/env bash 

Porque, no freeBSD, o bash está localizado em /usr/local/bin/bash

Comentários

• ” right ” é uma palavra difícil de usar nesses casos. Talvez uma frase melhor seria ” menos propensa a erros “.
• Isso também é terrível; a suposição de que / usr existe é uma má IMO. O Haiku, por exemplo, não tem / usr.

Você pode usar o vi para corrigir os dois problemas se existirem:

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

Comentários

• As respostas devem ser autocontidas o máximo possível. A pergunta não menciona dois problemas; se você pretende construir outras respostas, você deve pelo menos dizer quais são. Melhor ainda, você deve explicar como isso responde à pergunta.
• Correção muito rápida sem baixar mais ferramentas do Windows, obrigado!
• @ G-Man Outras respostas já mencionei isso com muito mais detalhes do que gostaria.Não há necessidade de repetir, mas se ‘ não for dolorosamente óbvio, você pode ter um final de linha do Windows e um caractere de BOM do Windows oculto. Acho que muitas pessoas que estão escaneando as respostas apreciam a brevidade em vez de serem autocontidas, especialmente quando há muito mais detalhes em outras respostas.

Se você não tiver o dos2unix, esta é uma maneira de corrigir o problema.

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

Marca de ordem de byte (BOM)

Isso pode ser causado por um BOM. Da Wikipedia, um BOM é um

A marca de ordem de byte (BOM) é um caractere Unicode, U + FEFF marca de ordem de byte (BOM) , cuja aparência como um número mágico no início de um fluxo de texto pode sinalizar várias coisas para um programa que consome o texto

Infelizmente, não sinaliza nada para o kernel do Linux que lida com a linha she-bang. Você pode verificar se tem um BOM usando file ,

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

Ou você pode hexdump os primeiros caracteres e ver se eles correspondem a qualquer um dos caracteres BOM manualmente

Você pode remover os caracteres BOM assim que os conhecer desta forma ,

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

Tive o problema ao adicionar acidentalmente um bash errado executável para o PATH e porque em meu script o #!/usr/bin/env bash shebang mais flexível foi usado (pegue o primeiro executável bash do caminho).

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

Eu instalei o GIT para Windows para funcionar em cygwin junto com as GUIs do Windows GIT (não estava funcionando com cygwin nativo git …). Resolvi isso agora mudando para #!/bin/bash sheband e removendo GIT para windows de PATH.

Experimente #!/bin/bash

Segunda coisa: find / -name bash
Terceira coisa: ls -al /bin/bash

Comentários

• Ou apenas which bash. Sabemos que ‘ está encontrando um porque ‘ está trabalhando com bash script.sh.
• Verdadeiro. E, como mencionado, existe o método / usr / bin / env muito mais portátil para que um programa localize o bash (ou outro interpretador) para você. Não há necessidade de codificar um pah.