executável no caminho, localizável pelo qual, ainda não pode executar sem o caminho de qualificação completa?

Question

Eu tenho um estranho problema de shell, com um comando no $ PATH que o shell (ksh, rodando no Linux) parece se recusar covardemente a invocar. Sem qualificar totalmente o comando, recebo:

#  mycommand
/bin/ksh: mycommand: not found [No such file or directory]

mas o arquivo pode ser encontrado pelo qual:

#  which mycommand
/home/me/mydir/admbin/mycommand

Eu também vejo explicitamente esse diretório em $ PATH:

#  echo $PATH | tr : '\n' | grep adm
/home/me/mydir/admbin

O exe nesse local parece normal:

#  file /home/me/mydir/admbin/mycommand
/home/me/mydir/admbin/mycommand: setuid setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped

# ls -l mycommand  
-r-sr-s--- 1 me mygroup 97892 2012-04-11 18:01 mycommand

e se eu o executar explicitamente usando um caminho totalmente qualificado:

#  /home/me/mydir/admbin/mycommand

Eu vejo a saída esperada. Algo está definitivamente confundindo a casca aqui, mas eu estou perdendo o que poderia ser?

EDIT: encontrar o que parecia ser uma pergunta semelhante: O binário não será executado quando executado com um caminho. Por exemplo, o programa não funciona, mas o programa funciona bem

Eu também testei mais de um desses comandos no meu $ PATH, mas encontrei apenas um:

# for i in 'echo $PATH | tr : '\n'' ; do test -e $i/mycommand && echo $i/mycommand ; done
/home/me/mydir/admbin/mycommand

EDIT2:

A partir desta manhã, o problema desapareceu e agora posso executar o executável.

Isso pode ser considerado como uma validação da sugestão de fazer logout e login, mas eu fiz isso ontem à noite sem sucesso. Esse logout / login também deve ter feito o equivalente a executar o comando 'hash -r' que foi sugerido (o qual fwiw também parece ser um ksh embutido, e não apenas um bash embutido).

Em resposta a algumas das respostas:

• Este é um executável, não um script (consulte a referência ELF na saída do comando de arquivo).

• Eu não acho que um strace teria ajudado. Isso acaba forçando o comando para executar totalmente qualificado. Eu suponho que eu poderia ter feito um anexo de strace no shell atual, mas desde que eu não posso mais reproduzir, não há nenhum ponto de tentar isso.

• não havia ponto e vírgula no $ PATH. Já que não posso mais reproduzir, não vou sobrecarregar essa questão com o $ PATH completo.

• tentar outro shell (ou seja, bash) teria sido algo que eu também teria tentado, como foi sugerido. Com o problema desaparecido, agora não sei se isso teria ajudado.

Também me foi sugerido verificar as permissões do diretório. Fazendo isso, para cada um dos diretórios até este eu vejo:

# ls -ld $HOME $HOME/mydir $HOME/mydir/admbin
drwxr-xr-x 10 me root    4096 2012-04-12 12:20 /home/me
drwxrwsr-t 22 me mygroup 4096 2012-04-12 12:04 /home/me/mydir
drwxr-sr-x  2 me mygroup 4096 2012-04-12 12:04 /home/me/mydir/admbin

A propriedade do diretório $ HOME está desarrumada (não deve ser o grupo raiz). Isso poderia causar outros problemas, mas não vejo como isso teria causado isso.

    

Answer 1

Você provavelmente precisará atualizar o cache de itens do seu shell no seu $PATH usando hash -r .

    

Answer 2

Além disso, em tais casos, verifique o que acontece quando o programa é chamado passando seu executável como um argumento para o vinculador dinâmico (pode se recusar a fazer isso enquanto setuid / setgid em alguns sistemas).

A saída de

ldd (1) dos dois casos também pode ser reveladora. "nenhum tal arquivo ou diretório" em um arquivo executável realmente significa que o linkador dinâmico especificado no arquivo executável não pode ser encontrado (imagine o executável com uma forma ELFin de #! / lib / ld-linux.what.so.ever dentro)

Este comportamento teve pessoas estupefatas que estavam lá para testemunhar o fim da era libc5, e agora, ocasionalmente, personifica pessoas na era do i386 / amd64 misto com diferentes meios de suportar dois conjuntos de bibliotecas em estado selvagem.

RPATH relativo no executável vs $ PWD?

PS a outra questão está relacionada ao MacOSX, que provavelmente usa o dyld e não o linker fornecido pela libc. Tipo muito diferente de animal.

    

Answer 3

Tudo bem, eu não tenho uma resposta. Eu provei algumas coisas e acho que posso acrescentar isso mais tarde:

• Criado um arquivo de teste - suas permissões mostram que ele é setuid e executável.
• Tentei defini-lo em um ponto de montagem com nosuid: ainda é executado
• Tentei defini-lo em um ponto de montagem com noexec: fornece um erro diferente

Então, por todas as contas, eu ainda estou confuso. Apenas por sorrisos e na chance de que isso seja um bug relacionado ao shell, você pode testá-lo com um shell diferente?

    

Answer 4

Eu estou supondo que o seu script não tem um shell válido após o # !. Por exemplo, em alguns sistemas SCO antigos, scripts com #! / Bin / bash não funcionam porque o bash REALMENTE vive em / usr / bin / bash. Burro, mas ei SCO está quase morto por um motivo, não?

Verifique seu shell e verifique se ele aponta para um binário / script real.

Edit: Ele não diz se é um script ou um binário, mas supondo que sua saída 'ls -l' esteja correta, então você provavelmente não tem um script de 93kbytes ... então este é provavelmente um significado binário minha resposta é totalmente incorreta.

Já tentou sair e voltar? Eu sei que se eu usar um binário que está em / usr / bin, em seguida, instalar uma versão / usr / local / bin da fonte, o sistema ainda tentará executar o original até que eu saia e volte.

    

Answer 5

Meus palpites:

• Você tinha um alias chamado mycommand . Por exemplo:

  alias mycommand=something
  

• Você tinha uma função chamada mycommand . Por exemplo:

  mycommand() { something; }
  

Na próxima vez que você tiver esse problema, tente executar command -V mycommand para ver que tipo de comando o shell acredita que mycommand é.

    

Answer 6

Sem resposta, apenas um monte de pensamentos:

1. Verifique se o nome do arquivo contém espaço em branco; isso é ignorado silenciosamente ao usar o preenchimento de tabulação e usá-lo como parâmetro.
2. Tente outro script / programa no diretório.
3. Tente ligar o shell tentando executar o script e ver onde ele quebra.

Answer 7

Eu tive exatamente o mesmo problema e não consegui encontrar uma resposta porque o problema do pôster original se resolveu. Mas isso não funcionou para mim e eu finalmente consegui rastrear o problema. Então, estou adicionando o seguinte como resposta para a postagem original.

Os sintomas que enfrentei foram os seguintes. Existe um script (myscript.pl) no / my / home diretório. Agora tentando executá-lo:

> /my/home/myscript.pl
myscript.pl:  permission denied.

Permissão verificada do arquivo (o sinalizador de execução está definido). Verificado $ PATH (embora não deva haver um problema).

Então, tento (depois de verificar se o sinalizador de executável está definido no script):

> cd /my/home/
> ./myscript.pl:  permission denied.

Hmmm ... Então talvez o script não esteja chamando a linguagem de script correta (perl, neste caso). O topo do script tem a mágica correta:

#!/usr/bin/perl

e, de fato, o / usr / bin / perl existe e funciona. Então, a chamada a seguir funciona corretamente.

/usr/bin/perl myscript.pl

A guia completa de

não mostrará o arquivo (nem em tcsh nem em bash ).

Isso realmente me jogou fora. Então lembrei que alguns meses atrás meu disco caiu, e o jovem administrador do sistema em meu laboratório reinstalou o sistema. Pensei que ele poderia ter estragado as permissões nas partições. E, de fato, em /etc/fstab , a permissão exec estava faltando!

/dev/sda1    /my     /ext4      rw,user

Em vez de

/dev/sda1    /my     /ext4      rw,user,exec

Corrigido isso alterando /etc/fstab e remontando:

mount -v -o remount /my

Isso resolveu o problema completamente. Meu palpite é que uma coisa semelhante pode ter acontecido com o problema do pôster original, exceto que o problema de permissão era intermitente (por exemplo, houve uma alteração temporária que poderia ter sido resolvido com uma reinicialização, se ocorresse).