Perché devo `fonte .profile` in ogni terminale che apro?

Quando cambiamo alcune variabili in ~/.profileUbuntu, eseguiamo il comando source .profile. Quindi la modifica è effettiva solo in questo terminale. Se apriamo un nuovo terminale, dobbiamo eseguire source .profilenuovamente il comando . Quindi sembra che terminali diversi abbiano il proprio ambiente sebbene possano appartenere allo stesso utente.

Qual è il vantaggio di fare in modo che ogni terminale abbia il proprio percorso ambientale? Sembra che sarebbe meglio se un terminale diverso appartenente allo stesso utente condividesse la stessa variabile d'ambiente.

La ragione di ciò è che ~/.profileproviene solo dalle shell di login. Quando si apre una nuova finestra del terminale, la shell che si avvia è una shell non di accesso per impostazione predefinita. Se ci si disconnette e si riconnette, la modifica ~/.profilesarà effettiva in tutti i terminali, poiché ~/.profileproviene quando si accede alla sessione.

Non è il caso che finestre terminali diverse abbiano un ambiente diverso, ma che il sourcing venga ~/.profileeseguito solo ~/.profilenella shell corrente (è esattamente ciò che fa il sourcecomando).

Al contrario, una modifica a ~/.bashrcinfluenzerà immediatamente qualsiasi nuova finestra del terminale aperta o qualsiasi shell Bash che inizi digitando bash, poiché proviene da tutte le shell Bash interattive.

Le variabili d'ambiente non sono solo per le preferenze dell'utente. Sono un meccanismo generico per comunicare una varietà di informazioni di impostazione da un processo genitore a processi secondari che inizia.

Esistono numerosi casi in cui un processo imposta variabili di ambiente specifiche per influenzare solo i processi che inizia. Ad esempio, uno script può ripristinare deliberatamente le impostazioni locali per i comandi che avvia, in modo da poter analizzare l'output da essi. Gli script di build per molti pacchetti software di grandi dimensioni utilizzano invocazioni nidificate di makequelle coordinate tra loro attraverso variabili di ambiente. Strumenti speciali potrebbero dover cambiare le condizioni di lavoro di altri programmi che iniziano facendo trucchi con $ LD_PRELOAD o $ PATH.

Se qualcosa che un utente fa in una finestra diversa mentre è in esecuzione una lunga compilation in un'altra, cambierebbe magicamente le variabili d'ambiente di tutti i suoi processi dietro le loro spalle, la follia e il caos risulterebbero.

Altre variabili di ambiente contengono informazioni sulla particolare sessione in cui viene avviato un processo. I programmi prevedono $ TERM per descrivere il set di comandi del particolare terminale (o emulatore di terminale) a cui sono connessi; rendendo un'impostazione generale per utente, sarebbe impossibile accedere allo stesso sistema con diversi tipi di terminali. Anche se hai solo un pezzo di hardware terminale e non accedi mai in remoto, programmi come screendipendono dall'impostazione di un $ TERM diverso per i processi eseguiti all'interno della loro sessione.

Una domanda migliore sarebbe: perché utilizziamo un meccanismo di comunicazione da processo a sottoprocesso per le impostazioni delle preferenze dell'utente, piuttosto che un database per utente?

Risposta: Perché funziona abbastanza bene e i vantaggi della creazione di un database per utente non sono abbastanza grandi da fare il lavoro di modifica di tutto per usare quello al posto delle variabili di ambiente.

(Posso pensare a pochissime impostazioni delle preferenze in cui non ci sarebbero alcuni casi d'uso in cui è conveniente cambiarli solo per l'esecuzione di un singolo script, ad esempio. Quindi, per non perdere la funzionalità, tutto dovrebbe comunque essere sovrascritto da variabili di ambiente, che si traducono in maggiore complessità e utenti più confusi).

Non è come se non esistessero alternative . Ad esempio, le risorse X sono per sessione di visualizzazione anziché per processo. Ma sono difficili da accedere per i programmi da riga di comando e i programmi da riga di comando di solito devono funzionare per accessi remoti che non hanno nemmeno un server X a cui connettersi.