¿Dónde se establece la variable de entorno $ HOME?

16

Estoy buscando el lugar donde se establece la variable de entorno $ HOME. Es después de iniciar sesión, en mi opinión.

Estoy usando Linux debian 2.6.32-5-686.

linux environment-variables

— tarde
fuente

2

Si está intentando modificar su INICIO, puede hacerlo

export HOME=/home/...

ya sea en su shell, o en su archivo ~ / .profile y / o ~ / .bashrc (o el shell de inicio de sesión apropiado).

(El código anterior funcionará para bash y shells similares, que son predeterminados en Debian; de lo contrario, haría `setenv HOME $ HOME: / extra / path, creo que en shells similares a csh en otras distribuciones).

editar - Sin embargo, esta probablemente no sea la forma de hacerlo. Ver otras respuestas. No uses esta respuesta.

— usuario76871
fuente

Es probable que te confundas $HOMEcon $PATH. No tiene sentido tener múltiples rutas $HOME(el valor completo se tratará como un solo nombre de ruta) o, en la mayoría de los casos, modificar $HOMEen absoluto.

— user1686

@grawity: perdón, gracias. Lamentablemente no puedo eliminar mi respuesta.

— user76871

21

En Linux, el HOMEprograma de inicio de sesión establece la variable de entorno:

por loginla consola, telnet y rlogin sesiones
por sshdpara conexiones SSH
por gdm, kdmo xdmpara sesiones gráficas.

— usuario1686
fuente

8

El programa de inicio de sesión lo organiza antes de llamar a exec en su shell (incluyéndolo en los argumentos de exec), en función del valor en / etc / passwd.

— bmargulies
fuente

1

Interesante esto no obtuvo más votos. Es la única respuesta que realmente especifica dónde se establece la variable de entorno, que era la pregunta real del OP.

— Mike Williamson

5

Editar la siguiente orden: usermod -d /home/whatever_dir whatever_user.

Tenga en cuenta que este (obviamente) será el nuevo directorio de inicio. Bash lo hará cdal iniciar sesión, así que asegúrese de que exista y que los permisos sean correctos. Además, no se olvide de .bashrc, .profile, .xinitrc, etc; si no están en el directorio de inicio, no serán leídos.

De usermod:

Usage: usermod [options] LOGIN

Options:
  -c, --comment COMMENT         new value of the GECOS field
  -d, --home HOME_DIR           new home directory for the user account
  -e, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -f, --inactive INACTIVE       set password inactive after expiration
                                to INACTIVE
  -g, --gid GROUP               force use GROUP as new primary group
  -G, --groups GROUPS           new list of supplementary GROUPS
  -a, --append                  append the user to the supplemental GROUPS
                                mentioned by the -G option without removing
                                him/her from other groups
  -h, --help                    display this help message and exit
  -l, --login NEW_LOGIN         new value of the login name
  -L, --lock                    lock the user account
  -m, --move-home               move contents of the home directory to the
                                new location (use only with -d)
  -o, --non-unique              allow using duplicate (non-unique) UID
  -p, --password PASSWORD       use encrypted password for the new password
  -R, --root CHROOT_DIR         directory to chroot into
  -s, --shell SHELL             new login shell for the user account
  -u, --uid UID                 new UID for the user account
  -U, --unlock                  unlock the user account

— Synthead
fuente

0

Investigué un poco, y la respuesta a esto es un poco sorprendente. Tome el siguiente script de prueba y chmod +x:

#!/bin/bash 
printf 'My home is: '
echo  ~ || echo 'nowhere'

Podemos ejecutarlo ./test.shy ver:

Mi casa es: / home / user

Echemos un vistazo debajo del capó con strace.

$ strace ./test.sh |& grep '^open[a-z]*'

openat (AT_FDCWD, "/etc/ld.so.cache", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY | O_CLOEXEC) = 3
openat ( AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/ dev / tty", O_RDWR | O_NONBLOCK) = 3
openat (AT_FDCWD, "/ usr / lib / locale / locale-archive", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/ usr / lib / x86_64-linux-gnu / gconv / gconv-modules.cache ", O_RDONLY) = 3
openat (AT_FDCWD," ./test.sh ", O_RDONLY) = 3

No veo ninguna mención de HOME, archivos rc o passwd. Probémoslo con un ambiente limpio:

env -i bash
echo $HOME  #this will be blank since we cleared the env

Nada, como se esperaba. Ejecutemos el script en el entorno en blanco.

env -i bash
./test.sh

Mi casa es: / home / user

Interesante, el guión puede llegar a casa. Ahora vamos a rastrear.

strace ./test.sh |& grep '^open[a-z]*'

Ahora vemos:

openat (AT_FDCWD, "/etc/ld.so.cache", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY | O_CLOEXEC) = 3
openat ( AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/ dev / tty", O_RDWR | O_NONBLOCK) = 3
openat (AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/etc/ld.so. caché ", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD," /lib/x86_64-linux-gnu/libnss_compat.so.2 ", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD," /etc/ld.so.cache " , O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_nis.so.2 ", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/lib/x86_64-linux-gnu/libnsl.so.1", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/ etc / passwd", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "./test.sh", O_RDONLY) = 3

He marcado las líneas interesantes. Como podemos ver, parece que cuando $HOMEno está definido, el shell intentará completarlo, incluso cuando no esté en modo de inicio de sesión o interactivo.

— DeusXMachina
fuente