Perché la fonte ~ / .profile di default di Ubuntu ~ / .bashrc?

Questi sono i contenuti dello stock ~/.profilefornito con il mio 13.10 (righe commentate rimosse):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Questo è ereditato da Debian ma perché Canonical ha deciso di tenerlo? Per quanto ne so, non è il modo standard * nix e ho visto vari sistemi in cui ciò non è accaduto, quindi presumo che debbano aver avuto una buona ragione. Ciò può causare comportamenti imprevisti quando si eseguono shell di login (come ad esempio quando si immette un computer nel computer) in cui l'utente non si aspetterebbe di aver effettuato la ricerca ~/.bashrc.

L'unico vantaggio che mi viene in mente è di non confondere l'utente con molti file di avvio e consentire loro di modificare .bashrcda soli e di leggerlo indipendentemente dal tipo di shell. Questo, tuttavia, è un vantaggio dubbio poiché è spesso utile avere impostazioni diverse per il login e per le shell interattive e questo ti impedisce di farlo. Inoltre, le shell di accesso molto spesso non vengono eseguite in un ambiente grafico e ciò può causare errori, avvisi e problemi (oh mio!) A seconda di ciò che hai impostato in quei file.

Allora perché Ubuntu fa questo, cosa mi sto perdendo?

Questa è una decisione a monte proveniente da Debian. La logica di ciò è spiegata in questo bellissimo post del wiki , di cui il seguente è un estratto. Il riepilogo esecutivo è "per garantire che gli accessi GUI e non GUI funzionino allo stesso modo":

Prendiamo xdm come esempio. un giorno pierre torna dalle vacanze e scopre che il suo amministratore di sistema ha installato xdm sul sistema Debian. Si collega bene e xdm legge il suo file .xsession ed esegue fluxbox. Tutto sembra andare bene fino a quando non riceve un messaggio di errore nella locale errata! Poiché sostituisce la variabile LANG nel suo .bash_profile e poiché xdm non legge mai .bash_profile, la sua variabile LANG è ora impostata su en_US anziché fr_CA.

Ora, la soluzione ingenua a questo problema è che invece di avviare "xterm", potrebbe configurare il suo gestore di finestre per avviare "xterm -ls". Questo flag dice a xterm che invece di lanciare una shell normale, dovrebbe lanciare una shell di login. Con questa configurazione, xterm genera / bin / bash ma inserisce "- / bin / bash" (o forse "-bash") nel vettore argomento, quindi bash si comporta come una shell di login. Ciò significa che ogni volta che apre un nuovo xterm, leggerà / etc / profile e .bash_profile (comportamento bash incorporato), e poi .bashrc (perché .bash_profile dice di farlo). All'inizio può sembrare che funzioni bene - i suoi file dot non sono pesanti, quindi non si accorge nemmeno del ritardo - ma c'è un problema più sottile. Avvia anche un browser web direttamente dal suo menu Fluxbox, e il browser Web eredita la variabile LANG da fluxbox, che ora è impostata sulla locale errata. Quindi, anche se i suoi xterm potrebbero andare bene, e qualsiasi cosa lanciata dai suoi xterm potrebbe andare bene, il suo browser gli sta ancora dando pagine con impostazioni internazionali errate.

Quindi, qual è la migliore soluzione a questo problema? Non ce n'è davvero uno universale. Un approccio migliore è modificare il file .xsession in modo che assomigli a questo:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

Questo fa sì che la shell che interpreta lo script .xsession legga in / etc / profile e .bash_profile se esistono e sono leggibili, prima di eseguire xmodmap o xterm o "eseguire" il gestore di finestre. Tuttavia, c'è un potenziale svantaggio di questo approccio: in xdm, la shell che legge .xsession funziona senza un terminale di controllo. Se / etc / profile o .bash_profile utilizzano comandi che presuppongono la presenza di un terminale (come "fortuna" o "stty"), tali comandi potrebbero non riuscire. Questo è il motivo principale per cui xdm non legge quei file per impostazione predefinita. Se stai per utilizzare questo approccio, devi assicurarti che tutti i comandi nei tuoi "file dot" siano sicuri quando non ci sono terminali.

Questo è il comportamento standard di Ubuntu, ~/.bashrcè un file di avvio per shell interattivo a livello di utente. Quando si apre un terminale fondamentalmente si avvia una shell interattiva non di accesso che legge ~/.bashrce il contenuto di ~/.bashrcviene fornito ed esportato nel proprio ambiente di shell corrente. Aiuta a ottenere tutte le variabili e le funzioni della shell definite dall'utente nella shell corrente. Inoltre potresti trovare linee come questa

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

per ottenere alias definiti dall'utente nell'ambiente di shell corrente.

Questo è importante per fornire anche una buona esperienza utente. Per esempio si potrebbe memorizzare proxy delle credenziali .bashrc, a meno che non ottiene nessuna delle applicazioni del terminale di provenienza ( cioè , ping, wget, curl, lynxetc.) funzionerà correttamente. Oppure devi fornire le credenziali del proxy ogni volta che apri un terminale.

Oltre al valore predefinito di Ubuntu .bashrccontiene molti alias facili da usare (per lse grepstampare output colorati), molte nuove definizioni per diverse variabili shell che aumentano l'esperienza dell'utente.

Ma nel caso del tuo login ssh , o accedi alla console virtuale , in pratica ottieni una shell di accesso interattiva. Ecco il file di avvio della shell ~/.profile. Quindi, a meno che tu non ti stia ~/.bashrcperdendo, perdi tutte quelle impostazioni utili nel tuo .bashrc. Ecco perché la ~/.profilefonte predefinita di Ubuntu~/.bashrc

Caso da evitare

• non dovresti mai trovare la ~/.profileforma all'interno ~/.bashrcnello stesso momento in cui ~/.bashrcproviene da ~/.profile. Creerà un ciclo infinito di situazioni e di conseguenza il prompt del terminale verrà sospeso a meno che non si prema Ctrl+ C. In una situazione del genere se metti una linea nel tuo~/.bashrc

set -x

Quindi potresti vedere che il descrittore di file si sta arrestando quando apri un terminale.