Eu tenho um problema aparente bizarro de shell, com um comando no $ PATH que o shell (ksh, executando no Linux) parece covardemente se recusar 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

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 executá-lo explicitamente usando um caminho completo:

#  /home/me/mydir/admbin/mycommand

Eu vejo a saída esperada. Algo está definitivamente confundindo o shell aqui, mas estou sem saber o que poderia ser?

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

Também testei para 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 eu sou capaz de executar o executável.

Isso poderia ser considerado uma validação da sugestão de logout e login, mas eu fiz isso ontem à noite sem sucesso. Esse logout / login também deveria ter o equivalente à execução do comando 'hash -r' sugerido (que também parece ser um built-in do ksh, e não apenas um bash).

Em resposta a algumas das respostas:

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

• Eu não acho que um traço teria ajudado. Isso acaba forçando o comando a executar totalmente qualificado. Suponho que eu poderia ter feito uma ligação strace no shell atual, mas como não consigo mais me reproduzir, não há sentido em tentar isso.

• não havia ponto e vírgula no $ PATH. Como não posso mais me reproduzir, não vou desordenar esta questão com o $ PATH completo.

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

Também me foi sugerido que estava verificando as permissões do diretório. Fazendo isso, para cada um dos diretórios até este, 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 pode causar outros problemas, mas não vejo como isso teria causado esse problema.

Você provavelmente precisará atualizar o cache de itens do seu shell ao $PATHusá-lo hash -r.

Além disso, nesses casos, verifique o que acontece quando o programa é chamado passando seu executável como argumento ao vinculador dinâmico (pode se recusar a fazê-lo enquanto setuid / setgid em alguns sistemas).

A saída do ldd (1) de ambos os casos também pode ser reveladora. "nenhum arquivo ou diretório desse tipo" em um arquivo executável realmente significa que o vinculador dinâmico especificado no arquivo executável não pode ser encontrado (imagine o executável com o formato ELFin de #! / lib / ld-linux.what.so.ever dentro)

Esse comportamento deixou as pessoas estupefatas que estavam lá para testemunhar o fim da era libc5, e agora ocasionalmente estupefata as pessoas na era do i386 / amd64 misturado com diferentes meios de suportar dois conjuntos de bibliotecas na natureza.

RPATH relativo no executável vs $ PWD?

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

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

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

Então, por todas as contas, eu ainda estou tão confuso. Apenas para sorrisos e com a chance de isso ser um bug relacionado ao shell, você pode experimentá-lo com um shell diferente?

Estou supondo que seu script não tenha um shell válido após o # !. Por exemplo, em alguns sistemas SCO mais antigos, scripts com #! / Bin / bash não funcionam porque o bash REALMENTE vive em / usr / bin / bash. Burro, mas ei, a SCO está quase morta 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 possui um script de 93kbyte ... então esse provavelmente é um binário, minha resposta é: totalmente incorreto.

Você já tentou sair e entrar novamente? Eu sei que se eu usar um binário que esteja em / usr / bin e instalar uma versão / usr / local / bin a partir da fonte, o sistema ainda tentará executar a versão original até que eu efetue logout e logon novamente.

Meus palpites:

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

  alias mycommand=something
  

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

  mycommand() { something; }
  

Da próxima vez que você tiver esse problema, tente executar command -V mycommandpara ver que tipo de comando o shell acredita mycommandser.

Sem resposta, apenas um monte de pensamentos:

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

Eu tinha 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 finalmente consegui rastrear o problema. Então, estou adicionando o seguinte como resposta à postagem original.

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

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

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

Então, eu tento (depois de verificar se o sinalizador 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). A parte superior do script tem a mágica correta:

#!/usr/bin/perl

e de fato / usr / bin / perl existe e funciona. Portanto, a seguinte chamada funciona corretamente.

/usr/bin/perl myscript.pl

a guia preenchimento automático não mostraria o arquivo (nem dentro tcshnem dentro bash).

Isso realmente me assustou. Lembrei-me de que, há alguns meses, meu disco rígido travou 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, /etc/fstabfaltava a permissão do executivo!

/dev/sda1    /my     /ext4      rw,user

Ao invés de

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

Corrigido isso alterando /etc/fstabe remontando:

mount -v -o remount /my

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

Não é uma resposta completa, mas queria relatar minha experiência, pois eu tinha exatamente o mesmo problema que o questionador e achava que isso poderia ajudar futuros usuários com o mesmo problema enlouquecedor. Eu poderia qual arquivo, e vê-lo no meu caminho, e até executá-lo, fornecendo o caminho completo, mas não poderia executá-lo de outra forma. No entanto, no meu caso, isso só aconteceu dentro de um subcasca (ou seja, quando foi executado a partir de um script, nesse caso, havia algumas subcascas aninhadas). Eu poderia executá-lo a partir da linha de comando.

Pouco antes do comando no script aninhado, imprimi o comando, por exemplo, echo $ (what mycommand)

mycommand: / home / me / bin / mycommand

Então eu tentaria executá-lo a partir do script pai:

/ home / me / bin / some_parent_script [72]: mycommand: not found [Nenhum arquivo ou diretório]

Assim como o interlocutor, não consegui diagnosticar a origem do problema. Meu PATH parecia certo, era capaz e o hash não revelou nenhuma entrada anterior do meu comando. No dia seguinte, quando entrei, tudo funcionou magicamente novamente. Agora, observarei aqui que houve um problema de sistema conhecido que ocorreu pouco antes de eu ver esse problema em que uma montagem foi remontada. Talvez seja uma pista?

Se eu não tivesse um arquivo de registro após o arquivo demonstrando que isso aconteceu, não acreditaria que fosse possível! Graças ao interlocutor, não me sinto mais louco!

PS: Acho que o user226160 não teve exatamente o mesmo problema que o repórter, mas parece relacionado e empresta credibilidade à teoria da montagem.