Establecer variables de entorno para gnome en wayland y bash en terminales virtuales (o ssh)

Gnome 3.22 usa wayland por defecto. Gnome en wayland no lee ~/.profile(o ~/.bash_profileo /etc/profile). Ver https://bugzilla.gnome.org/show_bug.cgi?id=736660 .

Tengo mis archivos de inicialización configurados de la siguiente manera:

• .bash_profileno hace nada más que fuente .profiley.bashrc
• .profilesolo establece variables de entorno como PATHyLC_MESSAGES
• .bashrcestablece algunos ajustes específicos de bash y alias y variables de entorno para aplicaciones como lessy grep.

El efecto (antes de wayland) fue el siguiente:

• cuando inicio sesión gráficamente .profilese leyeron y las variables de entorno como PATHy LC_MESSAGESse establecieron. cuando abro bash dentro de un emulador de terminal, .bashrcse lee.
• cuando inicio sesión en una terminal virtual, .bash_profilese leyó, que a su vez se lee .profiley .bashrc.
• Cuando inicio sesión con ssh, el comportamiento es similar al terminal virtual.

En todos los casos .profiley .bashrcfueron leídos y mi entorno fue configurado.

Entonces ahora gnome 3.22 usa wayland y wayland no lee .profile. ¿Cómo puedo configurar mis archivos de inicialización para que vuelva a tener los efectos descritos anteriormente?

Tenga en cuenta que no insisto en que .profilese lean ciertos archivos (como ). Lo que quiero es tener mi entorno configurado de manera sensata. Eso significa que quiero mantener configuraciones específicas de bash para los archivos de inicialización de bash y otras configuraciones para otros archivos de inicialización. También me gustaría no copiar la configuración en diferentes archivos.

Yo uso Arch Linux. Las respuestas para todas las distribuciones son bienvenidas. Cuando sugiera una solución alternativa, describa también los efectos secundarios y las ventajas y desventajas.

actualización de noviembre de 2017: por lo que yo entiendo, los desarrolladores de gnome han reconocido que la gente espera que sus archivos de configuración de shell de inicio de sesión ( .profiley .bash_profileen el caso de bash) se obtengan después del inicio de sesión. independientemente de texto o inicio de sesión gráfico. entonces mi caso de uso descrito anteriormente funciona de nuevo.

Aún así, los desarrolladores de GNOME quieren alejarse de iniciar un shell de inicio de sesión. parece que la dirección en la que van es usar environmentd de systemd:

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

parece que llevará un tiempo hasta que todos los métodos de inicio de sesión se adapten a environmentd.

La versión 233 de Systemd (marzo de 2017) agregó soporte para establecer variables de entorno en ~/.config/environment.d/*.conf. Vea la environment.dpágina de manual y la discusión que condujo a la función de este PR preliminar y este final .

Esta es la solución que uso para el mismo problema:

Paso 1

Cree una secuencia de comandos que las fuentes ~/.profiley hacer que la secuencia de comandos ejecutable. Digamos que es /path/to/startup.sh. Podría verse más o menos así:

#!/bin/bash
. ~/.profile

Paso 2

Cree una aplicación de escritorio para ejecutar el script. Para hacer esto, debe crear un .desktoparchivo y colocarlo ~/.local/share/applications(o /usr/share/applicationssi desea que funcione para todos los usuarios). Digamos que es ~/.local/share/applications/startup.desktop. Podría verse más o menos así:

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

Para obtener más información sobre .desktoparchivos, consulte aquí .

Paso 3

Cerrar sesión. Vuelva a iniciar sesión. Ahora debería poder buscar su aplicación en el menú de aplicaciones.

Etapa 4

Establezca esta aplicación como una aplicación de inicio. Para hacer esto, utilicé la herramienta de ajuste de Gnome y agregué mi aplicación a la lista en la pestaña Aplicaciones de inicio.

¡Y eso es! Ahora debería recuperar su antigua funcionalidad cada vez que inicie sesión. También conserva la estructura del archivo intacta, por lo que, cuando se solucione el error en Wayland, todo lo que necesita hacer es eliminar la aplicación de la lista de aplicaciones de inicio, eliminar los dos archivos y todo vuelve a la normalidad.

Editar más tarde

Como @Guss señala en los comentarios, esta solución no exportará variables de entorno porque startup.sh se ejecuta en su propio shell. Entonces necesitamos otra solución para esos.

Al leer la documentación de GNOME , puede ver que hay algunas alternativas. Lo único que pude poner a trabajar fue crear un archivo en/usr/share/gdm/env.d/ y, en ese archivo, colocar las variables a exportar. Sin embargo, esto significa que las variables se exportarán para todos los usuarios, por lo que terminé haciendo esto:

Digamos que tenemos dos usuarios, John y Sally . Para cada uno de ellos cree un archivo en /usr/share/gdm/env.d/, llamémoslos startup_john.envy startup_sally.env. En esos archivos, coloque las variables de entorno que se exportarán cuando comiencen una nueva sesión de GNOME.

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

En este punto, el problema es que ambos archivos se cargarán para ambos usuarios. Para resolver esto, establecemos el permiso en cada archivo de modo que solo su propietario pueda leer su contenido.

$ 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

No es la solución más elegante, estoy de acuerdo, pero, por lo que he probado, parece hacer el trabajo.