Imposta variabili d'ambiente per gnome su wayland e bash su terminali virtuali (o ssh)

Gnome 3.22 usa wayland per impostazione predefinita. Gnome on wayland non legge ~/.profile(o ~/.bash_profileo /etc/profile). Vedi https://bugzilla.gnome.org/show_bug.cgi?id=736660 .

Ho i miei file di inizializzazione impostati come segue:

• .bash_profilenon fa altro che fonte .profilee.bashrc
• .profileimposta solo variabili d'ambiente come PATHeLC_MESSAGES
• .bashrcimposta alcune impostazioni e alias specifici di bash e variabili di ambiente per applicazioni come lesse grep.

L'effetto (prima di Wayland) era il seguente:

• quando ho effettuato il login graficamente sono .profilestate lette e le variabili d'ambiente mi sono piaciute PATHe LC_MESSAGESimpostate. quando apro bash all'interno di un emulatore di terminale, allora .bashrcviene letto.
• quando eseguo il login sotto un terminale virtuale, allora è .bash_profilestato letto che a sua volta legge .profilee .bashrc.
• quando accedo usando ssh il comportamento è simile al terminale virtuale.

In tutti i casi .profilee .bashrcsono stati letti e il mio ambiente è stato impostato.

Quindi ora GNOME 3.22 usa Wayland e Wayland non legge .profile. Come posso impostare i miei file di inizializzazione in modo da avere di nuovo gli effetti come descritto sopra?

Nota che non insisto per la .profilelettura di alcuni file (come ). Quello che voglio è che il mio ambiente sia impostato in modo ragionevole. Ciò significa che voglio mantenere le impostazioni specifiche di bash nei file di inizializzazione di bash e altre impostazioni in altri file di inizializzazione. Inoltre, vorrei non copiare le impostazioni su file diversi.

Uso arch linux. Le risposte per tutte le distribuzioni sono benvenute. Quando si suggerisce una soluzione alternativa, descrivere anche gli effetti collaterali e i vantaggi e gli svantaggi.

aggiornamento novembre 2017: per quanto ho capito, gli sviluppatori di gnome hanno riconosciuto che le persone si aspettano che i loro file di configurazione della shell di login ( .profilee .bash_profilein caso di bash) provengano dopo il login. indipendentemente dal testo o dal login grafico. quindi il mio caso d'uso descritto sopra funziona di nuovo.

gli sviluppatori di gnome vogliono comunque abbandonare l'avvio di una shell di login. sembra che la direzione che stanno andando è usare environmentd da systemd:

https://in.waw.pl/~zbyszek/blog/environmentd.html

sembra che ci vorrà del tempo prima che tutti i metodi di accesso siano adattati a environmentd.

Systemd versione 233 (marzo 2017) ha aggiunto il supporto per l'impostazione delle variabili di ambiente in ~/.config/environment.d/*.conf. Vedi la environment.dpagina man e la discussione che ha portato alla funzionalità di questo PR preliminare e di quello finale .

Questa è la soluzione alternativa che utilizzo per lo stesso identico problema:

Passo 1

Creare uno script che genera ~/.profilee rendere eseguibile tale script. Chiamiamolo /path/to/startup.sh. Potrebbe assomigliare a questo:

#!/bin/bash
. ~/.profile

Passo 2

Creare un'applicazione desktop per eseguire lo script. Per fare ciò è necessario creare un .desktopfile e inserirlo ~/.local/share/applications(o /usr/share/applicationsse si desidera che funzioni per tutti gli utenti). Chiamiamolo ~/.local/share/applications/startup.desktop. Potrebbe assomigliare a questo:

[Desktop Entry]
Name=Startup
Keywords=startup
Exec=/path/to/startup.sh
Type=Application

Per ulteriori informazioni sui .desktopfile, vedere qui .

Passaggio 3

Disconnettersi. Accedi nuovamente. Ora dovresti essere in grado di cercare la tua applicazione nel menu delle applicazioni.

Passaggio 4

Imposta questa applicazione come applicazione di avvio. Per fare ciò ho usato lo strumento Gnome Tweak e ho aggiunto la mia applicazione all'elenco nella scheda Applicazioni di avvio.

E questo è tutto! Ora dovresti avere di nuovo la tua vecchia funzionalità ogni volta che accedi. Conserva intatta anche la struttura del file, quindi, quando il bug in Wayland viene riparato, tutto ciò che serve per rimuoverlo dall'elenco delle applicazioni di avvio, eliminare i due file e tutto è tornato alla normalità.

Modifica successiva

Come sottolinea @Guss nei commenti, questa soluzione alternativa non esporterà le variabili di ambiente perché startup.shviene eseguita nella propria shell. Quindi abbiamo bisogno di un'altra soluzione per quelli.

Leggendo dalla documentazione di GNOME puoi vedere che ci sono alcune alternative. L'unico che ho potuto lavorare era creare un file /usr/share/gdm/env.d/e, in quel file, posizionare le variabili da esportare. Tuttavia, ciò significa che le variabili verranno esportate per tutti gli utenti, quindi quello che ho finito per fare è questo:

Diciamo che abbiamo due utenti, John e Sally . Per ognuno di essi creare un file in /usr/share/gdm/env.d/, chiamiamoli startup_john.enve startup_sally.env. In quei file posizionare le variabili d'ambiente da esportare quando avviano una nuova sessione GNOME.

$ cat startup_john.env
VAR=1
$ cat startup_sally.env
VAR=2

A questo punto il problema è che entrambi i file verranno caricati per entrambi gli utenti. Per risolvere questo problema, impostiamo l'autorizzazione su ciascun file in modo tale che solo il suo proprietario possa leggerne il contenuto.

$ ls -l startup_john.env
-rw-r-----. 1 john john 4 Dec 27 15:17 startup_john.env
$ ls -l startup_sally.env
-rw-r-----. 1 sally sally 4 Dec 27 15:16 startup_sally.env

Non è la soluzione più elegante, sono d'accordo, ma, per quanto ho testato, sembra aver fatto il lavoro.