Provided by: manpages-de_4.15.0-9_all 
BEZEICHNUNG
os-release, initrd-release, extension-release - Betriebssystemidentifikation
ÜBERSICHT
/etc/os-release
/usr/lib/os-release
/etc/initrd-release
/usr/lib/extension-release.d/extension-release.ABBILD
BESCHREIBUNG
Die Dateien /etc/os-release und /usr/lib/os-release enthalten
Betriebssystemidentifizierungsdaten.
Das Dateiformat von os-release ist eine durch Zeilenumbrüche getrennte Liste von
umgebungsartigen, Shell-kompatiblen Variablenzuweisungen. Es ist möglich, die
Konfiguration aus Bourne-Shell-Skripten einzulesen, allerdings werden außer einfachen
Variablenzuweisungen keine Shell-Funktionalitäten unterstützt. (Das bedeutet,
Variablenexpansion wird explizit nicht unterstützt). Damit wird Anwendungen erlaubt, die
Datei einzulesen, ohne eine Shell-kompatible Ausführungseinheit zu implementieren.
Variablenzuweisungen müssen in doppelte oder einzelne englische Anführungszeichen
eingeschlossen werden, falls sie Leerzeichen, Semikola oder andere besondere Zeichen
außerhalb von A…Z, a…z, 0…9 enthalten. (Zuweisungen, die diese besonderen Zeichen nicht
enthalten, können auch in Anführungszeichen eingeschlossen werden, dies ist aber
optional.) Besondere Zeichen der Shell (»$«, Anführungszeichen, Rückwärtsschrägstrich,
Gravis) müssen im Shell-Stil mit Rückwärtsschrägstrichen geschützt werden. Alle
Zeichenketten sollten in UTF-8-Kodierung sein und nicht druckbare Zeichen sollten nicht
verwandt werden. Die Aneinanderreihung individueller Zeichenketten in Anführungszeichen
wird nicht unterstützt. Zeilen, die mit »#« beginnen, werden als Kommentar behandelt.
Leere Zeilen sind erlaubt und werden ignoriert.
Die Datei /etc/os-release hat vor /usr/lib/os-release Vorrang. Anwendungen sollten auf
erstere prüfen und deren Daten exklusiv nutzen, falls sie exsitiert, und nur auf
/usr/lib/os-release zurückfallen, falls sie fehlt. Anwendungen sollten nicht aus beiden
Dateien gleichzeitig Daten auslesen. /usr/lib/os-release ist der bevorzugte Ort, um
Betriebssystemveröffentlichungsinformationen wie Teile des Lieferantenbaums abzulegen.
/etc/os-release sollte ein relativer Symlink auf /usr/lib/os-release sein, um
Kompatibilität für Anwendungen bereitzustellen, die nur nach /etc/ schauen. Ein relativer
Symlink anstatt eines absoluten ist notwendig, damit der Link auch in einer Chroot oder
Initrd-Umgebung wie Dracut funktioniert.
os-release enthält Daten, die durch den Betriebssystemlieferanten definiert werden und
sollte im Allgemeinen durch den Administrator nicht geändert werden.
Da diese Datei nur Namen und Kennungen kodiert, sollte sie nicht lokalisiert werden.
Die Dateien /etc/os-release und /usr/lib/os-release können Symlinks auf andere Dateien
sein, aber es ist wichtig, dass diese Datei vom frühsten Zeitpunkt des Systemstarts an
verfügbar ist, und sie muss sich daher auf dem Wurzeldateisystem befinden.
os-release darf keine wiederholenden Schlüssel enthalten. Dennoch sollten Leseprogramme
den hinteren Eintrag in der Datei wählen, falls Wiederholungen auftreten, ähnlich wie das
beim Einlesen von Dateien durch die Shell passiert. Ein Leseprogramm darf bei
wiederholenden Einträge warnen.
Für eine längere Begründung für os-release lesen Sie bitte die Ankündigung von
/etc/os-release[1].
/etc/initrd-release
In der Initrd[2] spielt /etc/initrd-release die gleiche Rolle wie os-release im
Hauptsystem. Zusätzlich bedeutet die Existenz dieser Datei, dass das System in der
Initrd-Phase ist. /etc/os-release sollte ein Symlink auf /etc/initrd-release sein (oder
umgekehrt), so dass Programme, die nur nach /etc/os-release schauen (wie oben
beschrieben), korrekt funktionieren.
Der Rest dieses Dokuments, das von os-release berichtet, sollte so verstanden werden, dass
es auch für initrd-release gilt.
/usr/lib/extension-release.d/extension-release.ABBILD
/usr/lib/extension-release.d/extension-release.ABBILD spielt die gleiche Rolle für
Erweiterungsabbilder wie os-release für das Hauptsystem und folgt der Syntax und den Regel
wie in Dokumentation portabler Dienste[3] beschrieben. Der Zweck dieser Datei ist die
Identifizierung der Erweiterung und der Ermöglichung für das Betriebssystem, zu
überprüfen, dass das Erweiterungsabbild auf das zugrundeliegende Betriebssystem passt.
Dies wird typischerweise implementiert, indem geprüft wird, dass die Option ID=
übereinstimmt und entweder SYSEXT_LEVEL= existiert und auch übereinstimmt oder, falls das
nicht vorhanden ist, dass VERSION_ID= existiert und übereinstimmt. Dies stellt
ABI/API-Kompatibilität zwischen den Ebenen sicher und verhindert das Zusammenführen von
inkompatiblen Abbildern in einer Überlagerung.
In dem Dateinamen extension-release.ABBILD muss der ABBILD-Anteil genau auf den Dateinamen
des enthaltenden Abbildes mit entfernter Endung passen. Falls es nicht möglich ist, dass
ein stabiler Abbildname garantiert werden kann, kann diese Überprüfung gelockert werden:
falls genau eine Datei in dem Verzeichnis vorhanden ist, deren Name auf
»extension-release.*« passt und die Datei mit einem user.extension-release.strict xattr(7)
gesetzt auf die Zeichenkette »0« markiert ist, dann wird sie stattdessen verwandt.
Der Rest dieses Dokuments, der von os-release handelt, sollte so gelesen werden, das er
auch auf extension-release angewandt werden kann.
OPTIONEN
Die folgenden Betriebssystemidentifikationsparameter können mittels os-release gesetzt
werden:
Allgemeine Informationen zum Ermitteln des Betriebssystems
NAME=
Eine Zeichenkette, die das Betriebssystem identifiziert, ohne Versionskomponente und
für die Anzeige beim Benutzer geeignet. Falls nicht gesetzt, kann die Vorgabe
»NAME=Linux« verwandt werden.
Beispiele: »NAME=Fedora«, »NAME="Debian GNU/Linux"«.
ID=
Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb
von 0…9, a…z, ».«, »_« und »-«), die das Betriebssystem identifiziert, ohne
irgendwelche Versionsinformationen und geeignet für die Verarbeitung durch Skripte
oder zur Verwendung in erstellten Dateinamen. Falls nicht gesetzt, kann die Vorgabe
»ID=linux« verwandt werden. Beachten Sie, dass die Zeichenkette weiterhin in
Anführungszeichen eingeschlossen werden darf, obwohl sie keine Zeichen enthält, die
für die Shell das Einschließen in Anführungszeichen benötigten.
Beispiele: »ID=fedora«, »ID=debian«.
ID_LIKE=
Eine durch Leerzeichen getrennte Liste von Betriebssystemkennungen in der gleichen
Syntax wie die Einstellung ID=. Sie sollte Kennungen von Betriebssystemen auflisten,
die eng in Zusammenhang zu dem lokalen Betriebssystem im Hinblick auf Paketierung und
Programmierschnittstellen sind, beispielsweise eine oder mehrere
Betriebssystemkennungen auflisten, von denen das lokale Betriebssystem abgeleitet ist.
Ein Betriebssystem sollte im Allgemeinen nur andere Betriebssystemkennungen auflisten,
von denen es selbst abgeleitet ist, und nicht andere Betriebssysteme, die von ihm
abgeleitet sind, obwohl symmetrische Beziehungen möglich sind. Bauskripte und
ähnliches könnten diese Variable überprüfen, falls sie das lokale Betriebssystem
identifizieren müssen und der Wert von ID= nicht erkannt wird. Betriebssysteme sollten
in der Reihenfolge aufgelistet werden, wie eng das lokale Betriebssystem in Bezug zu
den aufgeführten steht, beginnend mit dem engsten. Dieses Feld ist optional.
Beispiele: Für ein Betriebssystem mit »ID=centos« wäre eine Zuweisung von
»ID_LIKE="rhel fedora"« geeeignet. Für ein Betriebssystem mit »ID=ubuntu« ist eine
Zuweisung »ID_LIKE=debian« geeignet.
PRETTY_NAME=
Ein schöner Betriebssystemname in einem Format, das zur Darstellung bei Benutzern
geeignet ist. Wie passend kann dies auf irgendeine Art den Release-Code-Namen oder die
Betriebssystemversion enthalten oder auch nicht. Falls nicht gesetzt, kann die Vorgabe
»PRETTY_NAME=Linux« verwandt werden.
Beispiel: »PRETTY_NAME="Fedora 17 (Beefy Miracle)"«.
CPE_NAME=
Ein CPE-Name für das Betriebssystem, in URI-Anbindungssyntax, gemäß der Gemeinsamen
Plattform-Aufzählungs-Spezifikation[4], wie von NIST vorgeschlagen. Dieses Feld ist
optional.
Beispiel: »CPE_NAME="cpe:/o:fedoraproject:fedora:17"«
VARIANT=
Eine Zeichenkette, die eine spezielle Variante oder Edition des Betriebssystems
identifiziert, die zur Darstellung bei Benutzern geeignet ist. Dieses Feld kann den
Benutzer darüber informieren, dass die Konfiguration dieses Systems einer speziellen
abweichenden Gruppe von Regeln oder einer Standardkonfigurationseinstellung
unterliegt. Dieses Feld ist optional und könnte nicht auf allen Systemen implementiert
sein.
Beispiele: »VARIANT="Server Edition"«, "VARIANT=»Smart Refrigerator Edition"«.
Beachten Sie: Dieses Feld dient nur Anzeigezwecken. Für programmgesteuerte
Entscheidungen sollte das Feld VARIANT_ID benutzt werden.
VARIANT_ID=
Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb
von 0…9, a…z, ».«, »_« und »-«), die eine spezielle Variante oder eine spezielle
Edition des Betriebssystems identifiziert. Dies kann von anderen Paketen interpretiert
werden, um eine abweichende Standardkonfiguration zu ermitteln. Dieses Feld ist
optional und könnte nicht auf allen Systemen implementiert sein.
Beispiele: »VARIANT_ID=server«, »VARIANT_ID=embedded«.
Informationen über die Betriebssystemversion
VERSION=
Eine Zeichenkette, die die Betriebssystemversion identifiziert, ohne irgendeinen
Betriebssystemnamen, möglicherweise einschließlich eines Code-Namens für das Release,
und für die Anzeige beim Benutzer geeignet. Dieses Feld ist optional.
Beispiele: »VERSION=17«, »VERSION="17 (Beefy Miracle)"«.
VERSION_ID=
Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb
von 0…9, a…z, ».«, »_« und »-«), die die Betriebssystemversion identifiziert, ohne
irgendwelche Betriebssystemnamensinformationen oder Release-Code-Namen und geeignet
für die Verarbeitung durch Skripte oder zur Verwendung in erstellten Dateinamen.
Dieses Feld ist optional.
Beispiele: »VERSION_ID=17«, »VERSION_ID=11.04«.
VERSION_CODENAME=
Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb
von 0…9, a…z, ».«, »_« und »-«), die den Release-Namen des Betriebssystems
identifiziert, ohne irgendwelche Betriebssystemnamensinformationen oder
Release-Versionen und geeignet für die Verarbeitung durch Skripte oder zur Verwendung
in erstellten Dateinamen. Dieses Feld ist optional und könnte nicht auf allen Systemen
implementiert sein.
Beispiele: »VERSION_CODENAME=buster«, »VERSION_CODENAME=xenial«.
BUILD_ID=
Eine Zeichenkette, das das Systemabbild eindeutig identifiziert, das ursprünglich als
Installationsgrundlage verwandt wurde. In den meisten Fällen werden VERSION_ID oder
IMAGE_ID+IMAGE_VERSION aktualisiert, wenn das gesamte Systemabbild während einer
Aktualisierung ersetzt wird. BUILD_ID kann in Distributionen verwandt werden, bei
denen die Version des ursprünglichen Installationsabbildes wichtig ist; VERSION_ID
würde sich während schrittweiser Systemaktualisierungen ändern, aber nicht BUILD_ID.
Dieses Feld ist optional.
Beispiele: »BUILD_ID="2013-03-20.3"«, »BUILD_ID=201303203«.
IMAGE_ID=
Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb
von 0…9, a…z, ».«, »_« und »-«), die ein spezielles Abbild des Betriebssystems
identifiziert. Dies ist für Umgebungen gedacht, in denen Betriebssystemabbilder als
umfassende und konsistente Betriebssystemabbilder vorbereitet, gebaut, ausgeliefert
und aktualisiert werden. Dieses Feld ist optional und könnte nicht auf allen Systemen
implementiert sein, insbesondere nicht auf solchen, die nicht über Abbilder verwaltet
werden, sondern aus einzelnen Paketen auf dem lokalen System zusammengesetzt und
aktualisiert werden.
Beispiele: »IMAGE_ID=vendorx-cashier-system«, »IMAGE_ID=netbook-image«.
IMAGE_VERSION=
Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb
von 0…9, a…z, ».«, »_« und »-«), die die Betriebssystemversion identifiziert. Dies ist
zur Verwendung mit dem oben beschriebenen IMAGE_ID gedacht, um verschiedene Versionen
des gleichen Abbilds zu unterscheiden.
Beispiele: »IMAGE_VERSION=33«, »IMAGE_VERSION=47.1rc1«.
Um zusammenzufassen: Falls die Abbildaktualisierungen als umfassende Einheiten gebaut und
ausgeliefert werden, passt IMAGE_ID+IMAGE_VERSION am besten. Falls andernfalls die
Aktualisierungen schließlich die vorher installierten Inhalte komplett ersetzen, wie dies
in einer typischen binären Distribution der Fall ist, sollte VERSION_ID verwandt werden,
um die Hauptveröffentlichungen des Betriebssystems zu kennzeichnen. BUILD_ID kann statt
oder zusätzlich zu VERSION_ID verwandt werden, wenn die Version des ursprünglichen
Systemabbildes wichtig ist.
Darstellungsinformationen und Links
HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL=
Links auf Ressourcen im Internet mit Bezug zu dem Betriebssystem. HOME_URL= sollte
sich auf die Homepage des Betriebssystems oder alternativ auf die Homepage der
bestimmten Version des Betriebssystems beziehen. DOCUMENTATION_URL= sollte sich auf
die Hauptdokumentationsseite für dieses Betriebssystem beziehen. SUPPORT_URL= sollte
sich auf die Hauptseite für Unterstützung für das Betriebssystem beziehen, falls es
eine solche gibt. Dies ist hauptsächlich für Anbieter, die Unterstützung dafür
bereitstellen. BUG_REPORT_URL= sollte sich auf die Hauptseite für die Fehlerdatenbank
für das Betriebssystem beziehen, falls es eine solche gibt. Dies ist hauptsächlich für
Betriebssysteme gedacht, die sich auf Qualitätssicherung der Gemeinschaft verlassen.
PRIVACY_POLICY_URL= sollte sich auf die Hauptseite der Datenschutzrichtlinie für das
Betriebssystem beziehen, falls es eine solche gibt. Diese Einstellungen sind optional
und es ist typisch, das nur ein Teil dieser Einstellungen bereitgestellt werden. Diese
URLs sind für die Angabe in Oberflächen »Über dieses System« gedacht, unter Links mit
den Überschriften »Über dieses Betriebssystem«, »Hilfe erhalten«, »Einen Fehler
berichten« oder »Datenschutzrichtlinie«. Diese Werte sollten im RFC3986-Format[5] sein
und sollten »http:«- oder »https:«-URLs und möglicherweise »mailto:« oder »tel:« sein.
Für jede Einstellung darf nur eine URL aufgelistet werden. Falls mehrere Ressourcen
referenziert werden müssen, wird empfohlen, eine Online-Anlaufstelle bereitzustellen,
auf der alle verfügbaren Ressourcen verlinkt sind.
Beispiele: »HOME_URL="https://fedoraproject.org/"«,
»BUG_REPORT_URL="https://bugzilla.redhat.com/"«.
LOGO=
Eine Zeichenkette, die den Namen eines Icons wie er in der
Freedesktop.org-Icon-Thema-Spezifikation[6] definiert ist, angibt. Dies kann von
graphischen Anwendungen zur Darstellung eines Logos des Betriebssystems oder des
Distributors verwandt werden. Dieses Feld ist optional und muss nicht notwendigerweise
auf allen Systemen implementiert sein.
Beispiele: »LOGO=fedora-logo«, »LOGO=distributor-logo-opensuse«
ANSI_COLOR=
Eine vorgeschlagene Farbe zur Darstellung des Betriebssystemnamens auf der Konsole.
Dies sollte als Zeichenkette angegeben werden, die zur Einbindung in den »ESC [ m
ANSI/ECMA-48«-Maskierungscode zum Setzen der graphischen Bildwiedergabe geeignet ist.
Dieses Feld ist optional.
Beispiele: »ANSI_COLOR="0;31"« für rot, »ANSI_COLOR="1;34"« für helles blau oder
»ANSI_COLOR="0;38;2;60;110;180"« für Fedora-blau.
Vorgaben und Metadaten auf Distributionsebene
DEFAULT_HOSTNAME=
Eine Zeichenkette, die den Rechnernamen festlegt, falls hostname(5) nicht vorhanden
ist und keine weitere Konfigurationsquelle den Rechnernamen festlegt. Muss entweder
ein freistehender DNS-Kennzeichner sein (eine Zeichenkette, die aus
7-Bit-ASCII-Zeichen in Kleinschreibung besteht und keine Leerzeichen und Punkte
enthält, begrenzt auf das Format, das für DNS-Domain-Namen erlaubt ist), oder eine
Abfolge solcher Kennzeichner, getrennt durch einzelne Punkte, die einen gültigen DNS
FQDN bildet. Der Rechnername darf höchstens 64 Zeichen lang sein, was eine
Linux-Begrenzung ist (DNS erlaubt längere Namen).
Siehe org.freedesktop.hostname1(5) für eine Beschreibung, wie
systemd-hostnamed.service(8) den Rückfall-Rechnernamen bestimmt.
SYSEXT_LEVEL=
Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb
von 0…9, a…z, ».«, »_« und »-«), die die Unterstützungsstufe für
Betriebssystemerweiterungen festlegt, um anzuzeigen, welche Erweiterungs-Abbilder
unterstützt werden. Siehe /usr/lib/extension-release.d/extension-release.ABBILD,
initrd[2] und systemd-sysext(8) für weitere Informationen.
Beispiele: »SYSEXT_LEVEL=2«, »SYSEXT_LEVEL=15.14«.
SYSEXT_SCOPE=
Akzeptiert eine Leerzeichen-getrennte Liste von einem oder mehreren Zeichenketten
»system«, »initrd« und »portable«. Dieses Feld wird nur in
extension-release.d/-Dateien unterstützt und zeigt an, auf welche Umgebungen die
Systemerweiterung anwendbar ist: d.h. reguläre Systeme, für initiale RAM-Dateisysteme
(»initrd«) oder für portierbare Diensteabbilder. Falls nicht festgelegt, wird
»SYSEXT_SCOPE=system portable« impliziert, d.h. jede Systemerweiterung ohne dieses
Feld ist auf reguläre Systeme und portierbare Diensteumgebungen anwendbar, aber nicht
auf Initrd-Umgebungen.
PORTABLE_PREFIXES=
Akzeptiert eine Leerzeichen-getrennte Liste von einem oder mehreren
Präfix-Übereinstimmungszeichenketten für die Logik der Portierbaren Dienste[3]. Dieses
Feld dient zwei Zwecken: Es informiert, kennzeichnet portierbare Diensteabbilder als
solche (und ermöglicht damit, dass sie von anderen Betriebssystemabbildern
unterschieden werden können, wie bootbaren Systemabbildern). Es wird auch verwandt,
wenn ein portierbares Diensteabbild angehängt wird: das festgelegte oder implizierte
portierbare Dienstepräfx wird gegen die hier festgelegte Liste geprüft, um
Beschränkungen, wie Abbilder an das System angehängt werden dürfen, durchzusetzen.
Hinweise
Falls Sie diese Datei verwenden, um das Betriebssystem oder eine bestimmte Version davon
zu ermitteln, benutzen Sie die Felder ID und VERSION_ID, möglicherweise mit ID_LIKE als
Rückfallwert. Wenn Sie nach einer Betriebssystemkennungszeichenkette für die Darstellung
beim Benutzer suchen, verwenden Sie das Feld PRETTY_NAME.
Beachten Sie, dass Betriebssystemanbieter sich entscheiden könnten, keine
Versionsinformationen zu liefern, beispielsweise um rollende Veröffentlichungen (»rolling
releases«) zu berücksichtigen. In diesen Fällen können VERSION und VERSION_ID ungesetzt
sein. Anwendungen sollte sich nicht darauf verlassen, dass diese Felder gesetzt sind.
Betriebssystemanbieter können das Dateiformat erweitern und neue Felder einführen. Es wird
nachdrücklich empfohlen, neuen Feldern einen betriebssystemspezifischen Namen
voranzustellen, um Namenskollisionen zu vermeiden. Anwendungen, die diese Datei lesen,
müssen unbekannte Felder ignorieren.
Beispiel: »DEBIAN_BTS="debbugs://bugs.debian.org/"«.
Verwalter von Containern und Sandbox-Laufzeitumgebungen können die Identifizierungsdaten
des Rechners Anwendungen zur Verfügung stellen, indem sie die Datei /etc/os-release (falls
verfügbar, andernfalls /usr/lib/os-release als Rückfalloptione) als /run/host/os-release
bereitstellen.
BEISPIELE
Beispiel 1. Datei os-release für Fedora Workstation
NAME=Fedora
VERSION="32 (Workstation Edition)"
ID=fedora
VERSION_ID=32
PRETTY_NAME="Fedora 32 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:32"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=32
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=32
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation
Beispiel 2. extension-release file für eine Erweiterung für Fedora Workstation 32
ID=fedora
VERSION_ID=32
Beispiel 3. os-release in sh(1) einlesen
#!/bin/sh -eu
# SPDX-License-Identifier: CC0-1.0
test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release'
. "${os_release}"
echo "Ausführung auf ${PRETTY_NAME:-Linux}"
if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then
echo "Sieht nach Debian aus!"
fi
Beispiel 4. os-release in python(1) (Version >= 3.10) einlesen
#!/usr/bin/python
# SPDX-License-Identifier: CC0-1.0
import platform
os_release = platform.freedesktop_os_release()
pretty_name = os_release.get('PRETTY_NAME', 'Linux')
print(f'Ausführung auf {pretty_name!r}')
if 'fedora' in [os_release.get('ID', 'linux'),
*os_release.get('ID_LIKE', '').split()]:
print('Sieht nach Fedora aus!')
Siehe Dokumentation für platform.freedesktop_os_release[7] für weitere Details.
Beispiel 5. os-release in python(1) (jede Version) einlesen
#!/usr/bin/python
# SPDX-License-Identifier: CC0-1.0
import ast
import re
import sys
def read_os_release():
try:
filename = '/etc/os-release'
f = open(filename)
except FileNotFoundError:
filename = '/usr/lib/os-release'
f = open(filename)
for line_number, line in enumerate(f, start=1):
line = line.rstrip()
if not line or line.startswith('#'):
continue
if m := re.match(r'([A-Z][A-Z_0-9]+)=(.*)', line):
name, val = m.groups()
if val and val[0] in '"\'':
val = ast.literal_eval(val)
yield name, val
else:
print(f'{filename}:{line_number}: ungültige Zeile {line!r}',
file=sys.stderr)
os_release = dict(read_os_release())
pretty_name = os_release.get('PRETTY_NAME', 'Linux')
print(f'Ausführung auf {pretty_name!r}')
if 'debian' in [os_release.get('ID', 'linux'),
*os_release.get('ID_LIKE', '').split()]:
print('Sieht nach Debian aus!')
Beachten Sie, dass die obige Version, die die eingebaute Implementierung verwendet, in den
meisten Fällen bevorzugt wird, und dass die hier bereitgestellte offen kodierte Version
als Referenz dient.
SIEHE AUCH
systemd(1), lsb_release(1), hostname(5), machine-id(5), machine-info(5)
ANMERKUNGEN
1. Ankündigung von /etc/os-release
http://0pointer.de/blog/projects/os-release
2. Initrd
https://www.kernel.org/doc/html/latest/admin-guide/initrd.html
3. Dokumentation portabler Dienste
https://systemd.io/PORTABLE_SERVICES
4. Gemeinsame Plattform-Aufzählungs-Spezifikation
http://scap.nist.gov/specifications/cpe/
5. RFC-3986-Format
https://tools.ietf.org/html/rfc3986
6. freedesktop.org-Icon-Thema-Spezifikation
http://standards.freedesktop.org/icon-theme-spec/latest
7.
platform.freedesktop_os_release
https://docs.python.org/3/library/platform.html#platform.freedesktop_os_release
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.