Ho un bizzarro problema di shell apparente, con un comando in $ PATH che la shell (ksh, in esecuzione su Linux) sembra rifiutare codardamente di invocare. Senza qualificare completamente il comando, ottengo:

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

ma il file può essere trovato con il quale:

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

Vedo anche esplicitamente quella directory in $ PATH:

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

L'ex in quella posizione sembra normale:

#  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 lo eseguo esplicitamente usando un percorso completo:

#  /home/me/mydir/admbin/mycommand

Vedo l'output previsto. Qualcosa sta sicuramente confondendo il guscio qui, ma sono in perdita quale potrebbe essere?

EDIT: trovare quella che sembrava una domanda simile: il binario non verrà eseguito quando eseguito con un percorso. Ad esempio, il programma> ./ non funzionerà ma> il programma funziona correttamente

Ho anche provato più di uno di questi comandi nel mio $ PATH, ma ne trovo 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 partire da questa mattina, il problema è svanito e ora sono in grado di eseguire l'eseguibile.

Questo potrebbe essere considerato come la convalida del suggerimento di disconnettersi e accedere, ma l'ho fatto ieri sera senza successo. Quel logout / login avrebbe dovuto fare anche l'equivalente dell'esecuzione del comando 'hash -r' che era stato suggerito (che fwiw sembra anche essere un built-in ksh, e non solo un built-in bash).

In risposta ad alcune delle risposte:

• Questo è un eseguibile non uno script (vedere il riferimento ELF nell'output del comando file).

• Non penso che una striscia avrebbe aiutato. Ciò finisce per forzare l'esecuzione del comando in modo completo. Suppongo che avrei potuto fare un attaccamento di strace sulla shell corrente, ma dal momento che non riesco più a riproporre non ha senso provarlo.

• non c'erano punti e virgola nel $ PATH. Dal momento che non riesco più a riproporre, non ingombrerò questa domanda con l'intero $ PATH.

• provare un'altra shell (cioè bash) sarebbe stato qualcosa che avrei anche provato, come suggerito. Con il problema risolto, ora non saprò se ciò avrebbe aiutato.

Mi è stato anche suggerito di controllare le autorizzazioni della directory. In questo modo, per ciascuna delle directory fino a questa vedo:

# 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 proprietà della directory $ HOME è incasinata (non dovrebbe essere un gruppo root). Ciò potrebbe causare altri problemi, ma non vedo come avrebbe causato questo.

Probabilmente dovrai aggiornare la cache degli elementi della shell durante l' $PATHutilizzo hash -r.

Inoltre, in questi casi, controlla cosa succede quando viene chiamato il programma passando il suo eseguibile come argomento al linker dinamico (potrebbe rifiutare di farlo mentre setuid / setgid su alcuni sistemi).

Anche l'output ldd (1) di entrambi i casi potrebbe rivelare. "nessun file o directory" su un file eseguibile significa in realtà che il linker dinamico specificato nel file eseguibile non può essere trovato (immagina che l'eseguibile abbia una forma ELFin di #! / lib / ld-linux.what.so.ever all'interno)

Questo comportamento aveva sbalordito le persone che erano lì per assistere alla fine dell'era libc5, e ora occasionalmente sbalordisce le persone nell'era del misto i386 / amd64 con diversi mezzi per supportare due set di librerie in natura.

RPATH relativo nell'eseguibile contro $ PWD?

PS, l'altra domanda è relativa a MacOSX, che probabilmente utilizza dyld e non il linker fornito da libc. Tipo di animale molto diverso.

Va bene, non ho una risposta. Ho dimostrato alcune cose e penso che potrei aggiungere a questo in seguito:

• Creato un file di test: le tue autorizzazioni mostrano che è setuid ed eseguibile.
• Ho provato a impostarlo su un mount point con nosuid: funziona ancora
• Ho provato a impostarlo su un mount point con noexec: dà un errore diverso

Quindi, a detta di tutti, sono ancora confuso. Solo per i sorrisi e per caso questo è un bug relativo alla shell, puoi provarlo con una shell diversa?

Immagino che il tuo script non abbia una shell valida dopo il # !. Ad esempio, su alcuni sistemi SCO meno recenti, gli script con #! / Bin / bash non funzionano perché bash vive REALMENTE in / usr / bin / bash. Stupido, ma hey SCO è quasi morto per un motivo, no?

Controlla la tua shell e assicurati che punti a un vero binario / script.

Modifica: Non dice se è uno script o un binario, ma supponendo che il tuo output 'ls -l' sia corretto, quindi probabilmente non hai uno script da 93kbyte ... quindi questo è probabilmente un binario che significa che la mia risposta è totalmente errato.

Hai provato a disconnetterti e riconnetterti? So che se uso un binario che è in / usr / bin, quindi installo una versione / usr / local / bin dalla fonte, il sistema tenta ancora di eseguire quello originale fino a quando non mi disconnetto e riconnetto.

Le mie ipotesi:

• Avevi un alias di nome mycommand. Per esempio:

  alias mycommand=something
  

• Avevi una funzione chiamata mycommand. Per esempio:

  mycommand() { something; }
  

La prossima volta che hai questo problema, prova a correre command -V mycommandper vedere che tipo di comando crede la shell mycommand.

Nessuna risposta, solo un mucchio di pensieri:

1. Controlla se il nome file contiene spazi bianchi; questo viene silenziosamente ignorato quando si utilizza il completamento di tabulazione e si utilizza come parametro.
2. Prova un altro script / programma nella directory.
3. Prova a rintracciare la shell cercando di eseguire lo script e vedere dove si rompe.

Ho avuto esattamente lo stesso problema e non sono riuscito a trovare una risposta perché il problema del poster originale si è risolto da solo. Ma questo non ha funzionato per me e alla fine sono riuscito a rintracciare il problema. Quindi sto aggiungendo quanto segue come risposta al post originale.

I sintomi che ho affrontato sono stati i seguenti. C'è uno script (myscript.pl) nella directory / my / home. Ora provando a eseguirlo:

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

Autorizzazione verificata del file (flag di esecuzione impostato). $ PATH verificato (anche se non dovrebbe esserci un problema).

Quindi provo (dopo aver verificato che il flag eseguibile sia impostato sullo script):

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

Hmmm ... Quindi forse lo script non sta chiamando il giusto linguaggio di scripting (perl, in questo caso). La parte superiore della sceneggiatura ha la magia corretta:

#!/usr/bin/perl

e infatti / usr / bin / perl esiste e funziona. Quindi la seguente chiamata funziona correttamente.

/usr/bin/perl myscript.pl

il completamento automatico della scheda non mostra il file (né in tcshné in bash).

Questo mi ha davvero colpito. Poi ho ricordato che qualche mese fa il mio disco rigido si è bloccato e il giovane amministratore di sistema nel mio laboratorio ha reinstallato il sistema. Pensò che avrebbe potuto rovinare i permessi sulle partizioni. E in effetti, in /etc/fstab, mancava l'autorizzazione exec!

/dev/sda1    /my     /ext4      rw,user

Invece di

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

Risolto il problema cambiando /etc/fstabe rimontando:

mount -v -o remount /my

Questo ha risolto completamente il problema. La mia ipotesi è che una cosa simile potrebbe essere accaduta con il problema del poster originale, tranne per il fatto che lì il problema dell'autorizzazione era intermittente (ad esempio, c'era un cambiamento temporaneo che avrebbe potuto essere risolto con un riavvio, se si fosse verificato).

Non una risposta completa, ma volevo riferire la mia esperienza poiché avevo lo stesso identico problema dell'interrogatore e pensavo che potesse aiutare i futuri utenti a riscontrare lo stesso problema esasperante. Potrei quale file, e vederlo nel mio percorso, e persino eseguirlo dando il percorso completo, ma non potrei eseguirlo altrimenti. Tuttavia, nel mio caso, è successo solo all'interno di una sotto-shell (cioè quando è stata eseguita da uno script, in questo caso c'erano alcune sotto-shell nidificate). Potrei eseguirlo dalla riga di comando bene.

Appena prima del comando nello script nidificato, ho stampato il comando, ad esempio echo $ (che il mio comando)

mycommand: / home / me / bin / mycommand

Quindi proverei a eseguirlo dallo script principale:

/ home / me / bin / some_parent_script [72]: mycommand: non trovato [Nessun file o directory simile]

Proprio come l'interrogante, non sono stato in grado di diagnosticare l'origine del problema. Il mio PERCORSO sembrava giusto, era in grado di farlo e l'hash non ha rivelato alcuna voce precedente del mio comando. Il giorno dopo, quando ho effettuato l'accesso, tutto ha funzionato magicamente di nuovo. Ora, noterò qui che si è verificato un problema di sistema noto appena prima di vedere questo problema in cui è stato rimontato un montaggio. Forse è un indizio?

Se non avessi il file di registro dopo il file di registro a dimostrazione che ciò è accaduto, non avrei creduto che fosse possibile! Grazie all'interrogatore, non mi sento più pazzo!

PS: Non credo che user226160 abbia avuto lo stesso ESATTO problema del reporter, ma sembra correlato e dà credito alla teoria del mount.