Cosa fanno gli script in /etc/profile.d?

Sto leggendo degli script di shell di base da Linux Command Line e Shell Scripting Bible .

Dice che il /etc/profilefile imposta le variabili di ambiente all'avvio della shell Bash. La /etc/profile.ddirectory contiene altri script che contengono file di avvio specifici dell'applicazione, che vengono eseguiti anche al momento dell'avvio dalla shell.

• Perché questi file non fanno parte di /etc/profilese sono anche fondamentali per l'avvio di Bash?

• Se questi file sono file di avvio specifici dell'applicazione non fondamentali per l'avvio di Bash, perché fanno parte del processo di avvio? Perché non vengono eseguiti solo quando vengono eseguite le applicazioni specifiche, per le quali contengono impostazioni?

Perché questi file non fanno parte di / etc / profile se sono anche fondamentali per l'avvio di Bash?

Se intendi "Perché non sono solo combinati in una sceneggiatura gigante?", La risposta è:

1. Perché sarebbe un incubo per la manutenzione delle persone responsabili degli script.
2. Poiché avere gli script caricati come moduli indipendenti rende l'intero sistema più dinamicamente regolabile, è possibile aggiungere e rimuovere singoli script senza influire sugli altri. Eccetera.
3. Perché sono caricati tramite / etc / profile che li rende comunque parte del "profilo" bash allo stesso modo.

Se questi file sono file di avvio specifici dell'applicazione non fondamentali per l'avvio di Bash, perché fanno parte del processo di avvio? Perché non vengono eseguiti solo quando vengono eseguite le applicazioni specifiche, per le quali contengono impostazioni?

Mi sembra una domanda più ampia sulla filosofia del design che dividerò in due. La prima domanda riguarda il valore e l'adeguatezza dell'uso dell'ambiente shell. Ha un valore positivo? Sì, è utile È la soluzione migliore a tutti i problemi di configurazione? No, ma è molto efficiente per la gestione di parametri semplici e anche ampiamente riconosciuto e compreso. Contrariamente a dire che, decidendo di configurare tali cose in modo eterogeneo, forse $ PATH potrebbe essere gestito da uno strumento indipendente separato, strumenti preferiti come $ EDITOR potrebbero essere in un file sqlite da qualche parte, $ LC lang stuff potrebbe essere in un file di testo con un formato personalizzato da qualche altra parte, ecc. - non solo usando variabili env e/etc/profile.dimprovvisamente sembra più semplice? Probabilmente sai già cos'è una variabile env, come funzionano e come usarle, rispetto all'apprendimento di 5 meccanismi completamente diversi per 5 diversi aspetti onnipresenti di ciò che viene appropriatamente chiamato "l'ambiente".

La seconda domanda è "L'avvio è il momento appropriato per questo?", Il che fa sorgere l'obiezione che non è molto efficiente (tutti quei dati che possono o non possono essere utilizzati, ecc.). Ma:

• Realisticamente, non sono tutti quei dati, in parte perché nessuno nella loro mente corretta li userebbe per più di alcuni semplici parametri (poiché ci sono altri mezzi per configurare un'applicazione).
• Se viene usato saggiamente, per quanto riguarda le cose che sono comunemente invocate, l'impostazione, ad esempio, $ CFLAGS predefinito da un file da qualche parte ogni volta che invochi gccsarebbe meno efficiente. Tieni presente che la quantità di memoria coinvolta è, di nuovo, infinitesimale.
• Può coinvolgere cose sistemiche con cui può essere coinvolta più di un'applicazione e la shell è un terreno comune .

Si potrebbe aggiungere altro a quell'elenco, ma si spera che questo ti dia qualche idea sui pro e contro del problema - il principale 'pro' e il principale 'contro' è che si tratta di uno spazio dei nomi globale.

Quei file sono specifici di un'applicazione, ma provengono all'avvio della shell, non all'avvio dell'applicazione. Una directory di configurazione viene utilizzata qui per lo stesso motivo per cui si trova in molti altri luoghi. Ciò consente a un'applicazione o un pacchetto software di modificare le configurazioni. Ciò non sarebbe possibile senza una configurazione divisa, poiché più pacchetti che provano a gestire / aggiornare un singolo file di configurazione che può anche essere modificato dall'utente sarebbero corretti e disordinati.

Anche una nota a /etc/profilemargine , è fornita da tutte le shell, non solo da bash. Il file di configurazione specifico di bash è bashrc e proviene solo da shell interattive.

la risposta di jordanm non è corretta. /etc/profilenon proviene da tutte le shell. Come hai sottolineato, non proviene da csh, tcsh- Non ne sono sicuro zsh. È fornito da shderivati Bourne shell ( ), come Korn Shell ( ksh) e BASH ( bash). cshusi /etc/login. Le persone che tendono ad usare esclusivamente derivati ​​di Borne Shell tendono a dimenticare che esistono altre conchiglie. Aggiungono qualcosa /etc/profileall'aspettarsi che si applichi a "tutti gli utenti" e poi sono sorpresi quando l'utente strano C Shell (e noi siamo un lotto strano) non ha le cose in cui ha configurato /etc/profile.

Anche così, le persone tendono a dimenticare l'esistenza di altri gusci derivati ​​da Borne Shell. Se usano basho ksh, si sentono liberi di aggiungere una sintassi /etc/profileche non è valida in Bourne Shell, come dire definire una variabile ed esportarla sulla stessa riga. Quindi ottieni alcuni script che lo fanno #!/bin/she soffoca sulla sintassi. /etc/profiledovrebbe attenersi alla sintassi compatibile Bourne Shell.

Allo stesso modo, dovresti attenerci a te stesso .profile(usa .bash_profilese vuoi una sintassi bash) - potrebbe essere un po 'di digitazione extra, ma è una digitazione extra che fai tutto in una volta. Riferimento ${HOME}e non ~, ecc. Alcune versioni di Unix, cron lavori eseguiti sh, ogni riga Makefileviene elaborata da sh, quindi se si lavora su più versioni di UNIX, è davvero importante mantenere la .profileshell Bourne compatibile. Come amministratore di sistema, non posso dirti quante volte ho aiutato qualcuno a sistemare la loro .profilecompatibilità con Bourne Shell.

Su Linux, /bin/shè un collegamento /bin/bashe quando lo si esegue, sembra un percorso utilizzato per eseguirlo e (in teoria) si limita solo alle cose supportate da Bourne Shell. Allo stesso modo, visu Linux è davvero vim, di nuovo limitandosi. Occasionalmente vengono visualizzate funzionalità "al vivo". Occasionalmente vimfingere di fare vifarà qualcosa che vimsupporta ciò viche non accade perché gli autori hanno vimdimenticato di disabilitarlo in modalità "vi retrocompatibilità". Non sarei sorpreso se bashfingere di avere shcaratteristiche simili "bleed through". Non sarebbe sorpreso se alcune funzionalità "funzionassero su Borne Shell su Linux", ma non su un UNIX basato su System V o BSD (AIX, OpenBSD, ecc.).