Dove è impostata la variabile d'ambiente $ HOME?

16

Sto cercando il luogo in cui impostare la variabile di ambiente $ HOME. È dopo il login, a mio avviso.

Sto usando Linux debian 2.6.32-5-686.

linux environment-variables

— webnoon
fonte

2

Se stai tentando di modificare la tua HOME, puoi farlo

export HOME=/home/...

nella shell o nel file ~ / .profile e / o ~ / .bashrc (o shell di accesso appropriata).

(Il codice sopra funzionerà per bash e shell simili, che sono predefinite in Debian; altrimenti si farebbe `setenv HOME $ HOME: / extra / path penso su shell tipo csh in altre distro.)

modifica - Tuttavia, probabilmente non è questo il modo di farlo. Vedi altre risposte Non usare questa risposta.

— user76871
fonte

È probabile che confondi $HOMEcon $PATH. Non ha senso avere più percorsi in $HOME(l'intero valore verrà trattato come un singolo percorso) o, nella maggior parte dei casi, modificare $HOMEaffatto.

— user1686

@grawity: scusa oops, grazie. Purtroppo non posso cancellare la mia risposta.

— user76871

21

Su Linux, la HOMEvariabile di ambiente è impostata dal programma di accesso:

dalle sessioni loginsu console, telnet e rlogin
by sshdper connessioni SSH
da gdm, kdmo xdmper sessioni grafiche.

— user1686
fonte

8

Il programma di login lo organizza prima di chiamare exec sulla shell (includendolo negli argomenti da exec), in base al valore in / etc / passwd.

— bmargulies
fonte

1

Interessante questo non ha ottenuto più voti. È l'unica risposta che specifica effettivamente dove è impostata la variabile di ambiente, che era la vera domanda del PO.

— Mike Williamson,

5

Modifica questo eseguendo: usermod -d /home/whatever_dir whatever_user.

Si noti che questa (ovviamente) sarà la nuova directory home. Bash lo farà cdall'accesso, quindi assicurati che esista e che le autorizzazioni siano corrette. Inoltre, non dimenticare .bashrc, .profile, .xinitrc, ecc; se non si trovano nella home directory, non verranno letti.

Da 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
fonte

0

Ho scavato e la risposta a questo è un po 'sorprendente. Prendi il seguente script di prova e procedi come segue chmod +x:

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

Possiamo eseguirlo con ./test.she vedere:

La mia casa è: / home / utente

Diamo una sbirciatina sotto il cofano.

$ 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, "/ us usr / lib / x86_64-linux-gnu / gconv / gconv-modules.cache ", O_RDONLY) = 3
openat (AT_FDCWD," ./test.sh ", O_RDONLY) = 3

Non vedo alcuna menzione di HOME, file rc o passwd. Proviamo con un ambiente pulito:

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

Niente, come previsto. Eseguiamo lo script nell'env vuoto.

env -i bash
./test.sh

La mia casa è: / home / utente

Interessante, la sceneggiatura è in grado di tornare a casa. Ora tracciamo.

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

Ora vediamo:

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. cache ", 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_RONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "/ etc / passwd", O_RDONLY | O_CLOEXEC) = 3
openat (AT_FDCWD, "./test.sh", O_RDONLY) = 3

Ho in grassetto le linee interessanti. Come possiamo vedere, sembrerebbe che quando $HOMEnon è definita, la shell proverà a riempirla, anche quando non è in modalità login o interattiva.

— DeusXMachina
fonte