Perché Bash non riesce a trovare il comando anche se $ PATH è specificato correttamente?


9

Sto specificando il percorso del mio comando nel file / etc / profile :

export PATH=$PATH:/usr/app/cpn/bin

Il mio comando si trova in:

$ which ydisplay 
/usr/app/cpn/bin/ydisplay

Quindi, quando eseguo l'output "echo $ PATH" appare come:

$ echo $PATH
...:/usr/app/cpn/bin

E va tutto bene, ma quando provo ad avviare il mio comando tramite SSH ricevo un errore:

$ ssh 127.0.0.1 ydisplay
$ bash: ydisplay: command not found

Ma il mio percorso è ancora presente:

$ ssh 127.0.0.1 echo $PATH
...:/usr/app/cpn/bin

Spiegami perché Bash non è riuscito a trovare ydisplay durante la sessione SSH e come configurare correttamente SSH per evitare questo problema.

Inoltre, se specifico $ PATH nel file locale .bashrc nell'attuale utente tutto funziona correttamente. Ma voglio modificare solo un file specificando invece molti file per ciascun utente. Questo è il motivo per cui lo sto chiedendo.


1
funziona solo la corsa ydisplay? fa ssh 127.0.0.1 /usr/app/cpn/bin/ydisplayil lavoro?
Bananguin,

@ user1129682 Sì, ydisplay con il nome completo specificato funziona e solo ydisplay funziona
SIGSEGV

Quando non sei loggato (non hai una sessione remota) ma inviando un comando da remoto non hai accesso alle variabili di ambiente allo stesso modo perché i tuoi file .bashrc / .profile non vengono eseguiti. Questo è il motivo in quanto sono responsabili dell'impostazione delle variabili per la sessione corrente.
mnmnc,

14
Solo una nota a margine: ssh 127.0.0.1 echo $PATHnon fa quello che potresti pensare che faccia: la shell espande $ PATH prima ancora che ssh sia eseguito, quindi ciò non prova o confuta nulla.
Ulrich Schwarz,

2
questa domanda StackOverflow potrebbe essere di aiuto
bsd

Risposte:


5

tl; dr

Esecuzione di ssh 127.0.0.1 ydisplayfonti ~/.bashrcanziché /etc/profile. Cambia invece il tuo percorso ~/.bashrc.

dettagli

L'unica volta che /etc/profilesi legge è quando la shell è una "shell di accesso".

Dal manuale di riferimento di Bash :

Quando bash viene invocato come shell di login, ... prima legge ed esegue i comandi dal file / etc / profile

Ma quando esegui ssh 127.0.0.1 ydisplay, bashnon viene avviato come shell di accesso. Tuttavia legge un altro file di avvio. Il Manuale di riferimento di Bash dice:

quando ... eseguito da ... sshd. ... legge ed esegue i comandi da~/.bashrc

Quindi dovresti inserire le tue PATHimpostazioni ~/.bashrc.

Sulla maggior parte dei sistemi, ~/.bash_profilefonti ~/.bashrc, in modo da poter inserire le impostazioni solo ~/.bashrcanziché inserirle in entrambi i file.

Non c'è modo standard per modificare le impostazioni per tutti gli utenti, ma la maggior parte dei sistemi hanno una /etc/bashrc, /etc/bash.bashrco simili.

In caso contrario, configurare pam_enve inserire l' PATHimpostazione /etc/environment.

Guarda anche:


1

Storicamente, i file del profilo ( /etc/profilee ~/.profile) sono stati invocati quando si è effettuato l'accesso (sulla console di testo, cos'altro?) E sono stati offerti molti scopi:

  • Impostare le variabili di ambiente e altri parametri (ad esempio umask) per la sessione.
  • Esegui programmi extra all'inizio della sessione (ad es. Notifica e-mail).
  • Esegui il programma per la sessione, se diverso dalla shell (ad esempio un'altra shell o X Window).
  • Impostare i parametri del terminale (ad es stty.).
  • Impostare i parametri della shell (ad es. Alias).

Tutti questi scopi non sono stati identificati come separati fino a dopo. Poiché gli script del profilo possono fare cose che hanno senso solo in una sessione interattiva (interazione terminale, avviare altri programmi), quando è stata introdotta l' invocazione della shell remota ( rsh ), le marche di rsh hanno deciso di non invocare la shell remota come shell di accesso, in modo che gli script del profilo non vengano eseguiti. (Alcune versioni di rshdhanno un'opzione per eseguire la shell remota come shell di login.) Ssh ha copiato questo comportamento per essere un sostituto drop-in per rsh.

Se si desidera eseguire gli script del proprio profilo, è possibile richiamarli in modo esplicito.

ssh 127.0.0.1 '. /etc/profile; . ~/.profile; ydisplay'

Nota il comando .per caricare gli script di profilo all'interno della shell: sono comandi da eseguire all'interno di quella shell, non un programma esterno.

Se si desidera impostare una variabile d'ambiente a livello globale per tutti gli utenti, esiste un altro metodo su molti sistemi: invece di definirla in /etc/profile, definirla in /etc/environment. Questo file viene letto attraverso il pam_envmodulo; la maggior parte delle distribuzioni Linux sono configurate per leggerlo.

Se la shell di accesso è bash, esiste un'ulteriore possibilità. Normalmente, non è necessario impostare le variabili di ambiente in.bashrc (poiché non verranno impostate nelle sessioni X tranne se si passa attraverso un terminale con una shell interattiva, perché non verranno impostate se si accede in modo interattivo su una console di testo o su ssh, perché sovrascriveranno le impostazioni personalizzate se invochi una shell all'interno di un altro programma). Tuttavia, bash ha una strana caratteristica che non ho mai capito: si legge ~/.bashrcin due circostanze non correlate:

  • nelle shell interattive che non sono shell di login;
  • nelle shell non interattive che non sono shell di login, se bash pensa che sia stato invocato da rshdo sshd.

Quando si esegue un comando su ssh, ci si trova nel secondo caso. Puoi organizzare la lettura del tuo profilo leggendo /etc/profilee .profileda .bashrc. Includi il seguente codice nel tuo ~/.bashrc:

case $- in
  *i*) :;; # this is an interactive shell, fine
  *) # This is not an interactive shell! This must be a non-interactive remote shell session.
    . /etc/profile; . ~/.profile
    return;;
esac
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.