it-swarm.com.de

Was machen die Skripte in /etc/profile.d?

Ich lese über grundlegende Shell-Skripte aus Linux Command Line und Shell Scripting Bible .

Es heißt, dass die /etc/profile Datei legt die Umgebungsvariablen beim Start der Bash Shell fest. Das /etc/profile.d Verzeichnis enthält andere Skripte, die anwendungsspezifische Startdateien enthalten, die ebenfalls beim Start von der Shell ausgeführt werden.

  • Warum sind diese Dateien nicht Teil von /etc/profile ob sie auch für den Bash-Start kritisch sind?

  • Wenn es sich bei diesen Dateien um anwendungsspezifische Startdateien handelt, die für den Bash-Start nicht kritisch sind, warum sind sie dann Teil des Startvorgangs? Warum werden sie nicht nur ausgeführt, wenn die spezifischen Anwendungen ausgeführt werden, für die sie Einstellungen enthalten?

93
asheeshr

Warum sind diese Dateien nicht Teil von/etc/profile, wenn sie auch für den Bash-Start kritisch sind?

Wenn Sie meinen: "Warum werden sie nicht einfach zu einem riesigen Skript zusammengefasst?", Lautet die Antwort:

  1. Denn das wäre ein Alptraum für die Leute, die für die Skripte verantwortlich sind.
  2. Da das Laden der Skripte als unabhängige Module das gesamte System dynamischer anpassbar macht, können einzelne Skripte hinzugefügt und entfernt werden, ohne die anderen zu beeinflussen. Usw.
  3. Weil sie über/etc/profile geladen werden, was sie sowieso auf die gleiche Weise zu einem Teil des Bash- "Profils" macht.

Wenn es sich bei diesen Dateien um anwendungsspezifische Startdateien handelt, die für den Bash-Start nicht kritisch sind, warum sind sie dann Teil des Startvorgangs? Warum werden sie nicht nur ausgeführt, wenn die spezifischen Anwendungen ausgeführt werden, für die sie Einstellungen enthalten?

Das scheint mir eine umfassendere Frage der Designphilosophie zu sein, die ich in zwei Teile aufteilen werde. Die erste Frage betrifft den Wert und die Angemessenheit der Verwendung der Shell-Umgebung. Hat es einen positiven Wert? Ja, das ist nützlich. Ist es die beste Lösung für alle Konfigurationsprobleme? Nein, aber es ist sehr effizient für die Verwaltung einfacher Parameter und auch weithin anerkannt und verstanden. Im Gegensatz dazu könnte $ PATH bei der Entscheidung, solche Dinge heterogen zu konfigurieren, möglicherweise von einem separaten unabhängigen Tool verwaltet werden. Bevorzugte Tools wie $ EDITOR könnten sich irgendwo in einer SQLite-Datei befinden, $ LC lang-Zeug könnte sich in einer Textdatei mit einem befinden benutzerdefiniertes Format woanders usw. - verwendet nicht nur env-Variablen und /etc/profile.d plötzlich einfacher erscheinen? Sie wissen wahrscheinlich bereits, was eine env-Variable ist, wie sie funktioniert und wie man sie verwendet, anstatt 5 völlig unterschiedliche Mechanismen für 5 verschiedene allgegenwärtige Aspekte dessen zu lernen, was entsprechend benannt "die Umgebung" ist.

Die zweite Frage lautet: "Ist der Start der geeignete Zeitpunkt dafür?", Was den Einwand aufwirft, dass er nicht sehr effizient ist (alle Daten, die möglicherweise verwendet werden oder nicht, usw.). Aber:

  • Realistisch gesehen sind es nicht allzu viele Daten, zum Teil, weil niemand, der bei klarem Verstand ist, sie für mehr als ein paar einfache Parameter verwenden würde (da es andere Möglichkeiten gibt, eine Anwendung zu konfigurieren).
  • Wenn es in Bezug auf Dinge, die häufig aufgerufen werden, mit Bedacht verwendet wird, ist es weniger effizient, beispielsweise jedes Mal, wenn Sie gcc aufrufen, die Standardeinstellung für $ CFLAGS aus einer Datei festzulegen. Beachten Sie, dass der Speicherbedarf wiederum infinitesimal ist.
  • Es kann systemische Dinge beinhalten, an denen mehr als eine Anwendung beteiligt sein kann, und die Shell ist eine Gemeinsamkeit.

Weitere könnten zu dieser Liste hinzugefügt werden, aber hoffentlich gibt Ihnen dies eine Vorstellung von den Vor- und Nachteilen des Problems - das Haupt- und Hauptproblem ist, dass es sich um einen globalen Namespace handelt.

77
goldilocks

Diese Dateien sind anwendungsspezifisch, werden jedoch beim Start der Shell bezogen und nicht beim Start der Anwendung. Ein Konfigurationsverzeichnis wird hier aus demselben Grund verwendet, aus dem es an vielen anderen Stellen gefunden wird. Dadurch kann eine Anwendung oder ein Softwarepaket Konfigurationen ändern. Dies wäre ohne eine geteilte Konfiguration nicht möglich, da mehrere Pakete, die versuchen, eine einzelne Konfigurationsdatei zu verwalten/zu aktualisieren, die auch vom Benutzer geändert werden kann, fehlerhaft und unübersichtlich wären.

Auch eine Randnotiz, /etc/profile wird von allen Muscheln bezogen, nicht nur von Bash. Die bash-spezifische Konfigurationsdatei ist bashrc und wird nur für interaktive Shells verwendet.

14
jordanm

Jordanms Antwort ist falsch. /etc/profile Wird nicht von allen Shells bezogen. Wie Sie hervorheben, wird es nicht von csh, tcsh bezogen - ich bin mir bei zsh nicht sicher. Es wird von Bourne Shell-Derivaten (sh) wie Korn Shell (ksh) und BASH (bash) bezogen. csh verwendet /etc/login. Menschen, die dazu neigen, ausschließlich Borne Shell-Derivate zu verwenden, neigen dazu, zu vergessen, dass andere Muscheln existieren. Sie fügen /etc/profile Etwas hinzu und erwarten, dass es für "alle Benutzer" gilt. Dann sind sie überrascht, wenn der ungerade C-Shell-Benutzer (und wir sind eine ungerade Menge) nicht über die in /etc/profile.

Trotzdem neigen die Leute dazu, andere existierende Borne Shell-Derivatschalen zu vergessen. Wenn sie bash oder ksh verwenden, können sie /etc/profile Syntax hinzufügen, die in Bourne Shell nicht gültig ist, z. B. eine Variable definieren und in dieselbe Zeile exportieren . Dann erhalten Sie ein Skript, das #!/bin/sh Ausführt und die Syntax erstickt. /etc/profile Sollte sich an die Bourne Shell-kompatible Syntax halten.

Ebenso sollten Sie sich in Ihrem eigenen .profile Daran halten (verwenden Sie .bash_profile, Wenn Sie eine Bash-Syntax wünschen) - es kann eine zusätzliche Extra-Eingabe sein, aber es ist eine zusätzliche Eingabe, die Sie alle einmal machen . Referenz ${HOME} Und nicht ~ Usw. Einige Varianten von Unix- und Cron-Jobs werden unter sh ausgeführt. Jede Zeile Ihres Makefile wird von sh Wenn Sie also mit mehreren UNIX-Varianten arbeiten, lohnt es sich wirklich, Ihre .profile Bourne Shell kompatibel zu halten. Als SysAdmin kann ich Ihnen nicht sagen, wie oft ich jemandem geholfen habe, indem ich seinen .profile So repariert habe, dass er mit Bourne Shell kompatibel ist.

Unter Linux ist /bin/sh Ein Link zu /bin/bash. Wenn Sie es ausführen, sieht es nach dem Pfad aus, der zum Ausführen verwendet wurde, und beschränkt sich (theoretisch) nur auf Dinge, die Bourne Shell verwendet unterstützt. Ebenso ist vi unter Linux wirklich vim, was sich wiederum selbst einschränkt. Gelegentlich sehen Sie Funktionen, die "durchbluten". Gelegentlich tut vim vor, vi zu sein, was vim unterstützt, dass vi dies nicht tut, weil die Autoren von vim vergessen haben, dies zu deaktivieren im Modus "vi Abwärtskompatibilität". Es würde mich nicht wundern, wenn bash, der vorgibt, sh zu sein, ähnliche "Durchblutungs" -Funktionen aufweist. Es würde mich nicht wundern, wenn eine Funktion "unter Borne Shell unter Linux funktioniert", aber nicht unter System V oder BSD-basiertem UNIX (AIX, OpenBSD usw.).

0
Damocles