Início / unix / Perguntas / 572241
Accepted
schrodingerscatcuriosity
Asked: 2020-03-11 14:52:39 +0800 CST

O nome da função Bash colide com o binário do sistema

  • 772

Em meus scripts tenho uma função chamada messages. Eu o escrevi no Linux Mint, sem problemas para executá-lo, e quando o mudei para uma estação Debian Buster, a função colidiu com /usr/bin/messages.

Eu tenho um script de inicialização que chama o script messages:

script_inicialização

# call to messages script
. messages

mensagens

messages() {
  # reformat the arguments and return them
}

mais tarde em startup_script

messages "This is a message"

Que lança

./startup_script: line 35: .: /usr/bin/messages: cannot execute binary file
messages: could not open mailbox `/path/to/my/script/<string passed to my function>': No such file or directory

Então eu recebo um monte de erros relacionados a /usr/bin/messagesser chamado em vez da minha função.

Após adicionar type messages "This is a message", a saída relevante é:

messages is /usr/bin/messages

Eu tenho a opção de renomear minha função¹, mas talvez haja uma maneira melhor de lidar com essa situação.

Como digo ao meu script para ignorar os binários do sistema e usar minhas próprias funções?

¹ A função é chamada em vários scripts, muitas vezes, então não é a opção mais fácil apenas mudar o nome.

bash shell-script

2 respostas

  1. Best Answer

    É assim que . filefunciona:

    Se filenão contiver uma <barra>, o shell deve usar o caminho de pesquisa especificado por PATHpara encontrar o diretório que contém o arquivo.

    Esse comportamento é especificado por POSIX .

    Seu primeiro erro é

    ./startup_script: line 35: .: /usr/bin/messages: cannot execute binary file

    É semelhante quando você chama . echo:

    -bash: .: /bin/echo: cannot execute binary file

    Você está tentando obter o arquivo binário /usr/bin/messages. Na verdade, seu arquivo onde a função está definida não é originado, a função não está definida no script atual. Isso significa que mais tarde messagesainda significa /usr/bin/messages, não a função.

    A linha relevante deve ser . ./messagesou . /full/path/to/messages(ou seja, caminho para seu arquivo, não para o binário).

    • 6

  2. Interpretando mensagens de erro

    Observe o número da linha na mensagem de erro . Dessa forma, você saberá em qual linha o erro está. Isso foi escondido de nós, pois você nos mostrou algumas linhas de um script contendo mais de 35 linhas.

    Qual arquivo é executado.

    Quando você especifica um arquivo com . file-to-sourceou file-to-run, os diretórios listados na variável de ambiente $PATHsão pesquisados ​​da esquerda para a direita. O diretório atual não está nesta lista, pois pode ser um risco de segurança, ou pelo menos ser confuso. Ele executa um programa no diretório atual, você deve especificar que está no diretório atual. por exemplo , . ./file-to-sourceou ./file-to-run(Não há necessidade de fornecer o caminho completo).

    Unixes costumavam ter .no PATH, até que se percebeu que isso era um problema. Por exemplo, coloque um programa chamado lsno diretório atual. CMD no Windows da Microsoft ainda tem .implicitamente no PATH, você não pode removê-lo. É uma das causas do alto valor de shopping, neste sistema operacional.

    Uma pegadinha

    .refere-se ao diretório de trabalho atual e não ao diretório em que o script está.

    Para resolver isso, algo assim pode ser feito.

    (
   cd "$(dirname "$(readlink -f "$0")")"
   script_dir="$(pwd)"
)
script_dir/other_script

    Espero que alguém possa vincular a uma solução melhor.

    • 1

relate perguntas