Perché un comando remoto SSH ottiene meno variabili di ambiente rispetto all'esecuzione manuale? [chiuso]

Ho un comando che funziona bene se eseguo SSH su una macchina ed eseguo, ma fallisce quando provo ad eseguirlo usando un comando remoto ssh come:

ssh user@IP <command>

Confrontando l'output di "env" utilizzando entrambi i metodi, si verifica il risultato in diversi ambienti. Quando accedo manualmente alla macchina ed eseguo env, ottengo molte più variabili di ambiente rispetto a quando eseguo:

ssh user@IP "env"

Qualche idea sul perché?

Esistono diversi tipi di shell. La shell di esecuzione del comando SSH è una shell non interattiva, mentre la shell normale è una shell di accesso o una shell interattiva. Segue la descrizione, da man bash:

       Una shell di login è quella il cui primo carattere di argomento
       zero è un - o uno è iniziato con l'opzione --login.

       Una shell interattiva è quella avviata senza opzione
       argomenti e senza l'opzione -c il cui input standard
       e l'errore sono entrambi collegati ai terminali (come determinato
       di isatty (3)), oppure uno è iniziato con l'opzione -i. PS1 è
       set e $ - include i se bash è interattivo, consentendo a
       shell script o un file di avvio per testare questo stato.

       I seguenti paragrafi descrivono come bash esegue i suoi
       file di avvio. Se uno dei file esiste ma non può esserlo
       leggi, bash segnala un errore. Le tilde sono espanse nel file
       nomi come descritto di seguito in Tilde Expansion in
       Sezione ESPANSIONE.

       Quando bash viene invocato come shell di login interattiva o come
       una shell non interattiva con l'opzione --login, per prima cosa
       legge ed esegue i comandi dal file / etc / profile, se
       quel file esiste. Dopo aver letto quel file, lo cerca
       ~ / .bash_profile, ~ / .bash_login e ~ / .profile, in quello
       ordine, legge ed esegue i comandi dal primo
       che esiste ed è leggibile. L'opzione --noprofile può
       essere usato quando si avvia la shell per inibire questo comportamento
       IOR.

       Quando esce una shell di login, bash legge ed esegue i comandi
       dal file ~ / .bash_logout, se esiste.

       Quando è una shell interattiva che non è una shell di accesso
       avviato, bash legge ed esegue i comandi da ~ / .bashrc,
       se quel file esiste. Questo può essere inibito usando il
       opzione --norc. L'opzione --rcfile forzerà bash
       per leggere ed eseguire comandi dal file anziché
       ~ / .Bashrc.

       Quando bash viene avviato in modo non interattivo, per eseguire una shell
       script, ad esempio, cerca la variabile BASH_ENV in
       l'ambiente, espande il suo valore se appare lì,
       e utilizza il valore espanso come nome di un file da leggere
       ed eseguire. Bash si comporta come se il seguente comando
       furono giustiziati:
              if [-n "$ BASH_ENV"]; poi . "$ BASH_ENV"; fi
       ma il valore della variabile PATH non viene utilizzato per la ricerca
       per il nome del file.

Che ne dici di cercare il profilo prima di eseguire il comando?

ssh user@host "source /etc/profile; /path/script.sh"

Si potrebbe trovare migliore per cambiare la situazione a ~/.bash_profile, ~/.bashrc, o qualsiasi altra cosa.

(Come qui (linuxquestions.org) )

L'ambiente Shell non viene caricato quando si esegue il comando ssh remoto. È possibile modificare il file di ambiente ssh:

vi ~/.ssh/environment

Il suo formato è:

VAR1=VALUE1
VAR2=VALUE2

Inoltre, controlla la sshdconfigurazione per l' PermitUserEnvironment=yesopzione.

Ho avuto un problema simile, ma alla fine ho scoperto che ~ / .bashrc era tutto ciò di cui avevo bisogno.

Tuttavia, in Ubuntu, ho dovuto commentare la riga che interrompe l'elaborazione ~ / .bashrc:

#If not running interactively, don't do anything
[ -z "$PS1" ] && return

Ho trovato una soluzione semplice per questo problema era aggiungere sorgente / etc / profile all'inizio del file script.sh che stavo cercando di eseguire sul sistema di destinazione. Sui sistemi qui, ciò ha causato la configurazione delle variabili ambientali necessarie per script.sh come se fossero in esecuzione da una shell di login.

In una delle risposte precedenti è stato suggerito di utilizzare ~ / .bashr_profile ecc .... Non ho trascorso molto tempo su questo, ma il problema è che se si invia a un utente diverso sul sistema di destinazione rispetto alla shell sul sistema di origine da cui si accede mi è sembrato che ciò causi l'utente del sistema di origine nome da usare per ~.

Esporta semplicemente le variabili di ambiente che desideri sopra il controllo per una shell non interattiva in ~ / .bashrc.