Dato che .bashrcè più "generico" (nel senso che lo .profilegenera), perché la procedura "include ~/binto path" non è dentro .bashrc? Perché l'utente non lo vorrebbe in una shell senza login? (Soprattutto al giorno d'oggi, dove le shell senza login sono più comuni *.)
So che posso fare manualmente questo cambiamento, ma voglio sapere se c'è un motivo.
* non posso provarlo, ma penso che sia così.
Risposte:
~/.bashrce /etc/bash.bashrcvengono eseguiti ogni volta che bashviene avviata una shell interattiva .
Al contrario, ~/.profilee /etc/profilevengono eseguiti ogni volta che viene avviata qualsiasi shell di accesso . Quindi non deve essere una bashshell, ma deve essere una shell di login (e molte bashistanze di shell non sono shell di login ).
bashshell è una shell in cui si trova il programma shell che lo fornisce bash, piuttosto che qualche altro programma, come dash.Pertanto, inserire un encomio che accoda le voci PATHin un bashrcfile dovrebbe:
Non fare nulla quando la shell non lo è bash, come spesso accade. Ad esempio, PATHsarebbe non modificato quando ci si trova in una sessione di accesso grafica. Ricorda, PATHnon viene utilizzato solo dai programmi da riga di comando.
Aggiungilo più volte in presenza di bashshell nidificate . Quindi, se avvii una shell all'interno di una shell - il che è molto comune, per una serie di motivi - allora avrai più ~/binvoci impilate sul tuo PATH. Ciò rende PATHdifficile leggere la variabile di ambiente e talvolta riduce anche le prestazioni.
Questi sarebbero indesiderabili. Quindi sarebbe sbagliato metterlo in un bashrcfile; appartiene davvero ~/.profile. ~/.profileè il posto giusto per:
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fiLe shell non di accesso hanno shell di accesso (o qualcosa che si comporta come una shell di accesso) come loro genitore ed ereditano la maggior parte delle variabili di ambiente, incluso PATH, da questa shell di accesso. Pertanto, inserire i comandi di modifica del percorso ~/.profilerichiede la disconnessione e il riavvio affinché siano efficaci, ma influisce anche sull'ambiente delle shell non di accesso (così come l'ambiente per i programmi che non sono shell, poiché ogni programma ottiene il suo proprio set di variabili d'ambiente - chiamato "ambiente" - ereditato dal suo processo genitore).
bindirectory privata non esistesse quando hai effettuato l'accesso e che l'hai creata durante questa sessione di accesso. Se esci e accedi di nuovo, sarà nel tuo PATH. Dal momento che la creazione della tua bindirectory privata è qualcosa che deve essere fatto solo una volta, questo è un inconveniente una tantum.