Tengo un extraño problema de shell aparente, con un comando en el $ PATH que el shell (ksh, que se ejecuta en Linux) parece negarse cobardemente a invocar. Sin calificar completamente el comando, obtengo:

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

pero se puede encontrar el archivo mediante el cual:

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

También veo explícitamente ese directorio en $ PATH:

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

El exe en esa ubicación 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

y si lo ejecuto explícitamente usando una ruta totalmente calificada:

#  /home/me/mydir/admbin/mycommand

Veo el resultado esperado. Algo definitivamente está confundiendo el caparazón aquí, pero no sé qué podría ser.

EDITAR: encontrar lo que parecía una pregunta similar: el binario no se ejecutará cuando se ejecute con una ruta. Por ejemplo,> ./ programa no funcionará pero> programa funciona bien

También probé más de uno de esos comandos en mi $ PATH, pero encuentro solo uno:

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

EDIT2:

A partir de esta mañana, el problema ha desaparecido y ahora puedo ejecutar el ejecutable.

Podría pensarse que valida la sugerencia de cerrar sesión e iniciar sesión, pero lo hice anoche sin éxito. Ese cierre de sesión / inicio de sesión también debería haber hecho el equivalente de ejecutar el comando 'hash -r' que se sugirió (que fwiw también parece ser un ksh incorporado, y no solo un bash incorporado).

En respuesta a algunas de las respuestas:

• Este es un ejecutable, no un script (consulte la referencia ELF en la salida del comando de archivo).

• No creo que un strace hubiera ayudado. Eso termina obligando al comando a ejecutar totalmente calificado. Supongo que podría haber hecho un strace adjunto en el shell actual, pero como ya no puedo reprochar, no tiene sentido intentarlo.

• no había punto y coma en el $ PATH. Como ya no puedo reprobar, no voy a abarrotar esta pregunta con el $ PATH completo.

• probar otro shell (es decir, bash) habría sido algo que también hubiera intentado, como se sugirió. Desaparecido el problema, ahora no sabré si eso habría ayudado.

También me sugirieron que revisara los permisos del directorio. Al hacerlo, para cada uno de los directorios hasta este veo:

# 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

La propiedad del directorio $ HOME está en mal estado (no debería ser un grupo raíz). Eso podría causar otros problemas, pero no veo cómo habría causado este.

Probablemente necesite actualizar el caché de elementos de su shell en su $PATHuso hash -r.

Además, en tales casos, verifique qué sucede cuando se llama al programa pasando su ejecutable como argumento al enlazador dinámico (podría negarse a hacerlo mientras se establece / establece en algunos sistemas).

El resultado de ldd (1) de ambos casos también puede ser revelador. "no existe tal archivo o directorio" en un archivo ejecutable realmente significa que no se puede encontrar el enlazador dinámico especificado en el archivo ejecutable (imagine que el ejecutable tiene una forma ELFin de #! / lib / ld-linux.what.so.ever dentro)

Este comportamiento dejó a la gente atónita que estaba allí para presenciar el final de la era de libc5, y ahora ocasionalmente deja atónita a las personas en la era de los mixtos i386 / amd64 con diferentes medios para soportar dos conjuntos de bibliotecas en la naturaleza.

¿RPATH relativo en ejecutable vs $ PWD?

PD: la otra pregunta está relacionada con MacOSX, que probablemente usa dyld y no el enlazador proporcionado por libc. Muy diferente tipo de animal.

Muy bien, no tengo una respuesta. Probé algunas cosas y creo que puedo agregar a esto más adelante:

• Creó un archivo de prueba: sus permisos muestran que es setuid y ejecutable.
• Intenté configurarlo en un punto de montaje con nosuid: todavía se ejecuta
• Intenté configurarlo en un punto de montaje con noexec: da un error diferente

Entonces, según todas las cuentas, todavía estoy tan confundido. Solo por sonrisas y si es un error relacionado con el shell, ¿puedes probarlo con un shell diferente?

Supongo que su script no tiene un shell válido después del # !. Por ejemplo, en algunos sistemas SCO más antiguos, los scripts con #! / Bin / bash no funcionan porque bash REALMENTE vive en / usr / bin / bash. Tonto, pero oye SCO está casi muerto por alguna razón, ¿no?

Verifique su shell y asegúrese de que apunte a un binario / script real.

Editar: no dice si es un script o un binario, pero suponiendo que su salida 'ls -l' sea correcta, entonces probablemente no tenga un script de 93kbytes ... así que probablemente sea un binario, lo que significa que mi respuesta es Totalmente incorrecto.

¿Has intentado cerrar sesión y volver a iniciarla? Sé que si uso un binario que está en / usr / bin y luego instalo una versión / usr / local / bin desde la fuente, el sistema aún intenta ejecutar el original hasta que cierre la sesión y vuelva a iniciarla.

Mis conjeturas:

• Tenías un alias llamado mycommand. Por ejemplo:

  alias mycommand=something
  

• Tenías una función llamada mycommand. Por ejemplo:

  mycommand() { something; }
  

La próxima vez que tenga este problema, intente ejecutar command -V mycommandpara ver qué tipo de comando cree el shell mycommand.

No hay respuesta, solo un montón de pensamientos:

1. Compruebe si el nombre del archivo contiene espacios en blanco; esto se ignora en silencio cuando se usa la finalización de tabulación y se usa como parámetro.
2. Pruebe con otro script / programa en el directorio.
3. Intenta alinear el shell tratando de ejecutar el script y ver dónde se rompe.

Tuve exactamente el mismo problema y no pude encontrar una respuesta porque el problema del póster original se resolvió por sí solo. Pero esto no funcionó para mí, y finalmente logré rastrear el problema. Entonces agrego lo siguiente como respuesta a la publicación original.

Los síntomas que enfrenté fueron los siguientes. Hay un script (myscript.pl) en el directorio / my / home. Ahora tratando de ejecutarlo:

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

Permiso verificado del archivo (se establece el indicador de ejecución). $ PATH verificado (aunque no debería haber un problema).

Entonces lo intento (después de verificar que el indicador ejecutable esté configurado en el script):

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

Hmmm ... Entonces quizás el script no está llamando al lenguaje de script correcto (perl, en este caso). La parte superior del guión tiene la magia correcta:

#!/usr/bin/perl

y de hecho / usr / bin / perl existe y funciona. Entonces la siguiente llamada funciona correctamente.

/usr/bin/perl myscript.pl

la pestaña autocompletar no mostraría el archivo (ni adentro tcshni adentro bash).

Esto realmente me echó. Luego recordé que hace unos meses mi disco duro falló y el joven administrador del sistema en mi laboratorio lo reinstaló. Pensé que podría haber arruinado los permisos en las particiones. ¡Y de hecho, en /etc/fstab, faltaba el permiso ejecutivo!

/dev/sda1    /my     /ext4      rw,user

En lugar de

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

Se solucionó esto cambiando /etc/fstaby volviendo a montar:

mount -v -o remount /my

Esto resolvió el problema por completo. Supongo que podría haber sucedido algo similar con el problema del póster original, excepto que allí el problema del permiso era intermitente (por ejemplo, hubo un cambio temporal que podría haberse resuelto con un reinicio, si hubiera tenido lugar).

No es una respuesta completa, pero quería informar mi experiencia ya que tenía exactamente el mismo problema que el interrogador, y pensé que podría ayudar a los futuros usuarios que experimentan el mismo problema enloquecedor. Podía obtener el archivo, y verlo en mi camino, e incluso ejecutarlo dando la ruta completa, pero no podría ejecutarlo de otra manera. Sin embargo, en mi caso, solo sucedió dentro de un sub-shell (es decir, cuando se ejecutó desde un script, en este caso hubo algunos sub-shells anidados). Podría ejecutarlo desde la línea de comandos muy bien.

Justo antes del comando en el script anidado, imprimí el comando, por ejemplo echo $ (que mi comando)

mycommand: / home / me / bin / mycommand

Luego intentaría ejecutarlo desde el script principal:

/ home / me / bin / some_parent_script [72]: mycommand: no encontrado [No existe tal archivo o directorio]

Al igual que el interrogador, no pude diagnosticar la fuente del problema. Mi RUTA se veía bien, era capaz y el hash no reveló ninguna entrada previa de mi comando. Al día siguiente, cuando inicié sesión, todo volvió a funcionar mágicamente. Ahora, notaré aquí que hubo un problema conocido del sistema que ocurrió justo antes de ver este problema en el que se montó una montura. Tal vez eso es una pista?

Si no tuviera un archivo de registro después del archivo de registro que demuestre que esto sucedió, ¡no creo que haya sido posible! Gracias al interrogador, ¡ya no me siento loco!

PD: No creo que el usuario 226160 tuviera el mismo EXACTO problema que el reportero, pero parece estar relacionado y da crédito a la teoría de la montura.