Contents
Informazioni generali
Le variabili d'ambiente (environ(7)) sono stringhe con nome disponibili per tutte le applicazioni. Le variabili sono usate per adattare il comportamento di ciascuna applicazione all'ambiente in cui viene eseguita. Si possono definire percorsi per i file, opzioni di lingua e così via. Si può controllare il manuale di ciascuna applicazione per vedere quali variabili vengano usate da essa.
Detto ciò, ci sono diverse variabili standard negli ambienti Linux:
- PATH = elenco di directory, separate dal carattere ":", in cui cercare i comandi;
- HOME = attuale directory home dell'utente;
- LOGNAME = il nome utente attuale;
- SHELL = la shell preferita dall'utente;
- PS1 = definisce il prompt dei comandi della shell;
- EDITOR = l'editor di testo preferito dell'utente;
- MAIL = la posizione della casella di posta elettronica in entrata dell'utente;
Per vedere le proprie variabili attualmente definite, aprire un terminale e digitare il comando "env".
Le variabili vengono definite con coppie nome-valore: "NOME=stringa qualsiasi come valore". Il nome della variabile solitamente è tutto in lettere maiuscole; tutto ciò che segue il segno di uguaglianza, fino al carattere di fine riga, è considerato come il valore della variabile. Le variabili possono essere definite ad hoc in un terminale scrivendo il comando appropriato. In Bash questo è export MIOVAL="Ciao mondo". In questo caso la variabile rimane definita fino alla fine della sessione di terminale.
Se si desidera aggiungere qualcosa ad una variabile, invece di sovrascrivere il valore precedente, includere il nome della variabile nella nuova definizione. Ad esempio, in Bash usare: "export PATH=$PATH:~/bin". Questo esempio mostra come aggiungere la directory bin all'interno della directory home dell'utente nella variabile d'ambiente PATH.
Nella maggior parte dei casi è molto comodo memorizzare queste variabili in un file di configurazione che viene letto all'avvio del sistema e quando l'utente fa il login, in modo che siano disponibili automaticamente. Sfortunatamente ciò non è sempre così semplice come sembra. Perché? Per un paio di ragioni.
- La maggior parte dei programmi non legge un file di configurazione per impostare il proprio ambiente; lo eredita, invece, da un processo genitore. È necessario configurare le impostazioni del genitore in modo che vengano passate a tutti i figli.
- I programmi genitori in questione sono spesso svariate shell e gestori di finestre, ma ciascuno di essi legge un file di configurazione (file punto) diverso quando viene avviato.
- Alcuni ambienti desktop avviano programmi attraverso un servizio ausiliario, e perciò il gestore di finestre potrebbe non essere il processo genitore.
Perciò ora è chiaro che deve essere considerato sia l'ordine di avvio dei processi di sistema, sia i file di configurazione che questi leggono all'avvio. Vedere la pagina sui file di configurazione, oppure continuare a leggere questa pagina ...
Andiamo al sodo! Ci sono diversi modi in cui si può accedere alla propria macchina Linux: da una console testuale, da login grafico (Display Manager) o usando ssh da remoto.
Usando la console testuale o ssh da remoto
Il login nella console testuale e il login con ssh da remoto risultano entrambi in una shell di login. Le variabili vengono acquisite in vari passaggi, da processi multipli in sequenza. Ogni processo aggiunge alcune variabili in più.
- Alla fine dell'avvio viene avviato "init", il genitore di tutti i processi. L'ambiente di init, compresa la variabile PATH, viene definito nel suo codice sorgente e non può essere modificato al momento dell'esecuzione.
init esegue gli script di avvio in /lib/systemd/system (in systemd) o /etc/rc?.d a seconda del runlevel impostato in /etc/inittab (in sysvinit). Ogni servizio o script definisce le proprie variabili di cui ha bisogno. Con systemd, le variabili definite in varie directory environment.d vengono rese disponibili alle unità utente di systemd; vedere la pagina di manuale environment.d(5) per i dettagli.
Alla fine del processo di avvio, init esegue un processo getty su una o più console virtuali. getty resta in attesa aspettando che un utente digiti il proprio nome e successivamente imposta la variabile TERM ed esegue login per chiedere la password.
login(1) controlla in /etc/passwd ed /etc/shadow i dettagli dell'account dell'utente. Se la password può essere accettata, login imposta HOME, SHELL, LOGNAME e MAIL sulla base del contenuto di /etc/passwd. Il valore di PATH value è impostato a partire dal file login.defs(5) (le voci di configurazione ENV_PATH e ENV_SUPATH in /etc/login.defs), ma è probabile venga scavalcato dalla shell sulla base di /etc/profile. SSH ha la propria configurazione e ignora il file login.defs.
Durante l'inizializzazione della sessione PAM il modulo pam_env(7) viene configurato in modo predefinito per leggere i file /etc/environment e /etc/default/locale. I file /etc/environment.d sono specifici per le sessioni di systemd e non hanno effetto sulle shell avviate da login o sshd.
- La shell di login viene avviata e legge i suoi file di configurazione specifici.
bash legge prima /etc/profile per ottenere i valori definiti per tutti gli utenti. Dopo aver letto tale file, controlla ~/.bash_profile, ~/.bash_login e ~/.profile, in questo ordine, e legge ed esegue i comandi nel primo di questi file che esiste ed è leggibile. Vedere DotFiles per i dettagli completi.
- (informazioni su altre shell sono benvenute)
Per i login con ssh i passaggi sono simili. Il sistema init esegue il servizio sshd che resta in ascolto per connessioni client remote.
sshd ha un ambiente di avvio definito dal suo file di servizio.
- PAM può fornire variabili aggiuntive.
/etc/ssh/sshd_config definisce variabili d'ambiente aggiuntive che possono essere accettate dal client.
- Dopo l'autenticazione, sshd esegue una shell di login che legge i suoi file punto specifici per la shell come descritto sopra.
Ora le variabili d'ambiente sono pronte per essere usate dalle aplicazioni che vengono avviate dalla shell.
Usare un graphical display manager
Il processo di login è piuttosto diverso se si usa un Display manager.
- Alla fine dell'avvio di sistema, viene avviato "init", il genitore di tutti i processi.
init esegue i servizi come descritto sopra. Uno di questi servizi è il display manager dell'utente.
Quando l'utente fa il login con successo, il display manager controlla PAM e poi avvia una sessione X.
PAM può dire al display manager di leggere le variabili in /etc/environment.
La sessione X legge ~/.xsessionrc ed eventualmente altri file a seconda del tipo di sessione.
Se i file di avvio della shell (/etc/profile e ~/.profile e così via) hanno o meno un effetto durante i login grafici dipende dal Display Manager. Per esempio SDDM li carica in modo predefinito mentre sono ignorati da LightDM nella configurazione predefinita in Debian. Un utente può scegliere di creare un file ~/.xsessionrc che legge questi file.
Ambienti desktop e servizi utente di systemd
Alcuni ambienti desktop avviano i programmi attraverso servizi utente di systemd. Questi programmi non ereditano il loro ambiente dalla sessione X. Per configurare l'ambiente per tali programmi, è necessario configurare il demone systemd --user.
Ciò può essere fatto nel modo seguente:
mkdir -p ~/.config/systemd/user/service.d
Usare il proprio editor di testo preferito per creare un file all'interno di questa directory. Il nome file deve terminare con .conf o non verrà riconosciuto. Supponiamo di usare env.conf come nome di file. All'interno del file env.conf scrivere le seguenti righe:
[Service] Environment="MIAVAR=un valore"
Per una lista di sequenze di escape usabili in questo file, vedere systemd.unit(5).
systemctl --user daemon-reload
- In alcuni ambienti desktop, può anche essere necessario riavviare un lanciatore o un servizio di menu, o forse disconnettersi e rifare il login.
Si può fornire più di una variabile d'ambiente e si possono anche configurare umask o limiti per le risorse (vedere Impostare l'umask predefinita per i dettagli). Si possono avere più file, oppure un solo file con più voci, come si preferisce.
environment.d(5) fornisce un altro modo per ottenere lo stesso risultato, ma è strettamente limitato alle variabili d'ambiente (non umask o limiti per le risorse) e usa una sintassi diversa. Inoltre non supporta gli specificatori (%h, ecc.) che systemd.unit(5) definisce, ma invece ha una sintassi di espansione di variabili in pseudo stile shell.
Per la risoluzione di problemi si possono usare i comandi seguenti:
$ systemctl --user show --property=Environment wireplumber.service Environment=GIO_USE_VFS=local $ systemctl --user show-environment HOME=/home/test LANG=en_GB.UTF-8 LANGUAGE=en_US:en ...
KDE
Le applicazioni lanciate da menu, KRunner o file di avvio automatico di XDG sono eseguiti come servizi di sessione utente di systemd, perciò il loro ambiente è configurato attraverso environment.d e file di unità di systemd. Alcuni valori impostati in file environment.d possono essere scavalcati:
il display manager, es. SDDM, può leggere /etc/profile, ~/.profile o file specifici per la shell.
- Nel caso di sessione X11 alcune variabili sono impostate attraverso Xsession, inclusi socket ssh e gpg agent.
Variabili LANG, LC_*, LANGUAGE della configurazione di localizzazione da ~/.config/plasma-localerc.
Configurazione specifica per KDE da file ~/.config/plasma-workspace/env/*.sh.
Le unità che fanno parte di default.target possono essere avviate prima che queste impostazioni abbiano effetto. Usare WantedBy=graphical-session.target o graphical-session-pre.target per i servizi avviato automaticamente che necessitano di configurazioni specifiche per KDE. Per esempio, SSH_AUTH_SOCK può essere impostato dopo aver avviato emacs.service e in questo caso particolare si può usare emacsclient --eval per aggiornare le variabili d'ambiente di Emacs usando un servizio ausiliario a singola esecuzione.
https://userbase.kde.org/Session_Environment_Variables Variabili di ambiente di sessione nel KDE UserBase Wiki
Guida rapida
Per coloro che hanno fretta e desiderano semplicemente far funzionare le cose, ecco cosa si può fare.
Mettere tutte le variabili d'ambiente globali, cioè quelle che hanno effetto per tutti gli utenti in /etc/environment
Ricordarsi che questo file viene letto da PAM, non da una shell. Non vi si possono usare espansioni di shell. Ad esempio, MAIL=$HOME/Maildir/ non funziona!
Non esiste una soluzione indipendente dalla shell e dal login al problema di come configurare l'ambiente per tutti gli utenti, a parte i casi banali che può gestire PAM.
Mettere tutte le impostazioni temporanea per la shell (alias, funzioni, opzioni della shell) in ~/.bashrc
Inserire tutte le variabili d'ambiente personali in ~/.profile.
Creare o modificare il file ~/.bash_profile e includervi i comandi:
if [ -f ~/.profile ]; then . ~/.profile fiCreare o modificare il file ~/.xsessionrc e includervi gli stessi comandi precedenti.
Se si usa un ambiente desktop creare un file env.conf come descritto nella sezione precedente.
Questo è un approccio veloce e non pulito! Non è per gli utenti iperattenti.
Note ed eccezioni
SysV, Systemd e init
Secondo GW in Re: PATH revisited: one PATH to "rule the [Debian] World", /sbin/init è ciò che viene eseguito dal kernel, indipendentemente da quale sistema init sia installato.
$ ps -fp 1 UID PID PPID C STIME TTY TIME CMD root 1 0 0 Oct07 ? 00:01:58 /sbin/init $ ls -l /sbin/init lrwxrwxrwx 1 root root 20 Sep 20 08:15 /sbin/init -> /lib/systemd/systemd*
Startx da terminale
Se si avvia il sistema X Window (la GUI) da una console testuale, le variabili d'ambiente sono già definite dalla shell di login, come spiegato precedentemente. Tuttavia, il gestore di finestre può rileggere gli stessi file un'altra volta (vedere in seguito). Ciò non è solitamente un problema, ma può avere risultati inaspettati come la variabile PATH che ha tutte le voci elencate due volte.
Shell a cascata
Se si avvia un'altra shell da quella di login (sì, è possibile farlo), la seconda è una shell "non di login". Non leggera i file di avvio nominati, ma cercherà invece gli script di avvio "non di login" nella directory home dell'utente. In bash è chiamato ~/.bashrc. Per evitare di specificare gli stessi valori in due posti, solitamente lo script di avvio della shell di login, ~/.bash_profile include ~/.bashrc alla fine della sua esecuzione. Per implementare questo sistema includere le righe seguenti nel proprio file ~/.bash_profile:
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
Finestra di terminale in X
Se si avvia una finestra di terminale/console nell'ambiente desktop grafico, si tratterà di un terminale non di login e leggerà solo lo script di avvio non di login dell'utente. Per Bash questo è ~/.bashrc.
Usando su
Il comando "su" viene usato per diventare un altro utente durante una sessione di login. È usato comunemente per ottenere temporaneamente i permessi di root da una sessione normale. In Stretch e versioni precedenti, il comando "su" reimposta il valore della variabile d'ambiente PATH a quello definito in /etc/login.defs dalle variabili ENV_PATH e ENV_SUPATH. In Buster e rilasci successivi, su in modo predefinito non cambia la variabile PATH (per i dettagli vedere /usr/share/doc/util-linux/NEWS.Debian.gz). Gli si può indicare di farlo creando il file /etc/default/su e mettendo la riga ALWAYS_SET_PATH yes al suo interno.
Notare che l'uso dello strumento Gnome "gksu" dal pannello di Gnome, usa in modo predefinito "su" internamente (cioè il proprio valore di PATH può andare perso se non lo si configura in login.defs, in stretch).