Diskussion:/dev/null

Lemma

Im Beitrag "Ausgabegerät" ist das Nullgerät bereits allgemein beschrieben, nicht nur für Unix, sondern auch andere BSe.

Ich weiß nicht, ob das Nullgerät einen eigenen Beitrag verdient. Wenn ja, sollte er sich mE auf alle (bekannten) Varianten beziehen.

Ich schlage also vor,

entweder die Unix-spezifischen Ausführungen dieses Artikels in den bereits vorhandenen Artikel "Ausgabegerät" zu integrieren

oder die dortigen Ausführungen hierher zu verschieben und dort einen Link hierher zu setzen.

Aus systematischen Gründen (dev/null ist eine Variante eines Nullgeräts, das Nullgerät ist ein -wenn auch virtuelles- Ausgabegerät) würde ich die erste Vorgehensweise bevorzugen.(Vorstehender nicht signierter Beitrag stammt von Woelfchen (Diskussion • Beiträge) 00:09, 22. Jul 2006)

Hm, nach 2,5 Jahren keine Antwort. Trotzdem bleibt es richtig. Interessant ist das Nullgerät an sich, nicht seine Betriebssystemspezifische Umsetzung in Unix/Linux. Also muss entweder das hier Geschriebene (stark komprimiert) in den Artikel Ausgabegerät, oder dort muss hierher verwiesen und hier der dortige Inhalt und das Lemma "Nullgerät" übernommen werden. Dev/Null darf gerne zu [Nullgerät] weiterleiten. -woelfchen 11:54, 11. Dez. 2008 (CET)

Ist /dev/null nicht ein feststehender Begriff, gerade auch in der Unix- sowie Netzkultur? --Robb der Physiker 18:09, 12. Dez. 2008 (CET)

Weiß ich nicht. /dev/null gibt es unter diesem Namen aber eben nur unter Unix/Linux, während es auf anderen Betriebssystemen anders heißt (nul:, nil:). Da könnten wir auch Grundlegendes zum Thema Auto unter "Mini Cooper" abhandeln...-woelfchen 20:56, 12. Dez. 2008 (CET)

Ich habe allerdings noch nie Nerds/Geeks über NUL reden gehört ;-) --Robb der Physiker 22:44, 14. Dez. 2008 (CET)

Und ich noch nix von Nerds und Geeks. Das Nullgerät ist doch nicht in erster Linie etwas "kulturelles", auch nichts "netzkulturelles", sondern eine Eigenschaft vieler Betriebssysteme. Warum nur auf Unix zu schauen, wo Win/DOS doch -jedenfalls außerhalb des Einsatzgebiets von Servern- viel verbreiteter ist ? -woelfchen 21:48, 15. Dez. 2008 (CET)

sinnloser Kopierbefehl?

Ich bin kein *IX-Experte, aber der Befehl

$ cp datei /dev/null

scheint mir reichlich sinnlos zu sein: die Kopie verschwindet im Nirwana, und das Original bleibt unverändert. Wäre

$ mv datei /dev/null

nicht sinnvoller, weil es praktisch einen Löschbefehl darstellt? --Plenz 08:39, 7. Apr. 2008 (CEST)

Ich habe grad kein *NIX zur Hand, aber ersetzen diese beiden Befehle nicht sogar /dev/null durch datei? --Robb der Physiker 15:55, 2. Okt. 2008 (CEST)

Habs eben getestet, cp funktioniert bei mir (es passiert gar nichts), mv ersetzt /dev/null. Der Befehl (cp datei /dev/null) an sich ist meiner Meinung nach wirklich nutzlos. --J3rry 09:09, 12. Sep. 2009 (CEST)

Würde es nicht andersrum eher funktionieren? cp /dev/null datei
-- Tuxman 22:17, 12. Sep. 2009 (CEST)

Je nachdem, was man unter "funktionieren" versteht. Dein Befehl legt eine 0 Byte große Datei an. Das kann ich auch mit touch (Unix). --Robb der Physiker 14:27, 7. Okt. 2009 (CEST)

Entschuldige, du hast Recht. Ich hatte an die "Inhalte" von /dev/null gedacht; die sind natürlich nicht existent. Denkfehler.
-- Tuxman 17:11, 7. Okt. 2009 (CEST)

 $ cp datei /dev/null

ist in manchen Fällen sinnvoll, weil datei im Filesystemcache landet. -- 87.158.184.105 00:56, 10. Dez. 2009 (CET)

Außerdem testet es, ob datei problemlos lesbar ist. --129.247.247.239 09:39, 18. Mai 2011 (CEST)

...und es ändert den inode-Inhalt, weil die atime geändert wird. --bakunin (Diskussion) 20:48, 13. Feb. 2014 (CET)

Ganz genau so ist es. cp datei /dev/null wird oft und gerne verwendet um 1. die Lesbarkeit der Datei festzustellen (es gibt sonst einen Rückgabewert, der nicht 0 ist) und um 2. den Inhalt der Datei in den Lesecache zu laden. Einem weiterer Lesezugriff wird dadurch extrem beschleunigt, allerdings lässt sich die Vorhaltezeit im Cache selbst nicht steuern.¹ ‣Andreas•⚖ 01:48, 11. Jul. 2018 (CEST)

Beispiele

Was genau ist der Grund dafür, dass die Beispiele für die Verwendung von /dev/null mit dieser Änderung komplett herausgeflogen sind?

Und was soll folgender Satz genau bedeuten?

Das Device dient dazu, als Adressat von Ausgaben zu fungieren, an denen man nicht interessiert ist.

Das ergibt deswegen keinen Sinn, weil man nicht definiert ist. Wenn ein Shellscript die Ausgaben nach /dev/null umleitet, so ist dies vom Script-Ersteller (Programmierer? Entwickler?) als unwichtig empfunden worden, oder aber er/sie ist nur am Ausgabewert interessiert, oder aber er/sie hällt die Ausgabe für den Script selbst für unpassend oder aber der Script würde wegen der Ausgabe nicht mehr richtig funktionieren. Umleitungen nach /dev/null sind in Shellscripten sehr häufig. Ich würde aber nicht sagen, dass man nicht an der Ausgabe interessiert ist.

Die Beispiele waren vielleicht nicht perfekt, aber sie gänzlich zu streichen halte ich für einen Fehler. Die Frage, wie man /dev/null sinnvoll verwenden kann, wird oft gestellt. Etwa hier oder hier (alles englisch). Und, ja, es ist natürlich auch möglich damit die Ausgabe eines Programmen zu ignorieren (siehe z.B. hier).

‣Andreas•⚖ 01:48, 11. Jul. 2018 (CEST)

Marke UNIX

Besteht irgendeine Notwendigkeit, die Marke UNIX im Artikel zu erwähnen? IMHO gibt es hierfür keinerlei Grund, denn das /dev/null gibt es nicht nur beim markengeschützten UNIX, sondern auch bei allen Lizenzprodukten und Klonen, egal wie sie heißen. Von daher ist die Verwendung der Marke hier vollständig entbehrlich. --Rôtkæppchen₆₈ 01:52, 11. Jul. 2018 (CEST)

Ich bin auch der Meinung. /dev/null gibt es auf allen unixoiden Systemen, nicht nur auf UNIX. ‣Andreas•⚖ 10:10, 11. Jul. 2018 (CEST)

Erstens: Was soll "unixoid" sein? Ist das sowas wie "DOSoär" oder "z/OSal"? Kann man, verfluchte Scheiße nocheinmal, nicht einfach "UNIX-ähnlich" schreiben anstatt irgendwelche bescheuerten Kunstworte zu erfinden? Und zweitens: ja, auf VIELEN (und nicht allen - oder kannst Du dafür eine Quelle angeben?) UNIX-ähnlichen Systemen gibt es ein Nulldevice. Lediglich der POSIX-Standard schreibt das Vorhandensein dieses Devices aber vor - alle anderen nicht. Aus genau dem Grund habe ich auch die Formulierung "UNIX [also Systeme, die dem POSIX-Standard entsprechen] und UNIX-ähnliche" gebraucht. UNIX ist nun mal eine Marke, ob Dir das paßt oder nicht. Wenn nun etwas etwas anderem ähnlich ist, dann wird das andere aber trotzdem korrekt geschrieben: "Mercedes und Mercedes-ähnliche Fahrzeuge" und nicht "Mercedes und MERceDES-ähnliche" und schon gar nicht "Mercedes und mercedesoide".

@Messerjokke: Habe ich jetzt meiner Diskussionspflicht Dir gegenüber, der grundsätzlich seine Änderungen nämlich niemals kommentiert oder begründet, sondern einfach tut, was ihm grade paßt (und oft genug Richtiges auf Falsches "verbessert", weil er nämlich nur wenig Ahnung von der Materie hat), Genüge getan? Du wirft mir wegen meiner Schreibweise "Vandalismus" vor (siehe Edit-Kommentar "diskutieren statt vandalieren"), aber selber hast du noch keinen einzigen deiner Edits diskutiert, sondern einfach was immer dir in den Kram paßte, getan. Es mag für dich überraschend sein, aber die Wikipedia ist nicht dein Privateigentum und da du bisher in den vielen Artikeln, die du nach mir hereditiert hast, noch keine einzige Quellenangabe beigesteuert hast, ist der Wert deiner Einlassungen reichlich zweifelhaft - um nicht zu sagen unenzyklopädisch. --bakunin (Diskussion) 15:24, 16. Aug. 2018 (CEST)

Nur ein kurzer Einwurf von mir: "unixoid" ist seit den 1990ern gebräuchlicht für ein Unix-Betriebssystem, das kein UNIX ist oder nicht zu 100% dem entspricht, was irgendwann einmal irgendjemand als ein richtiges Unix bezeichnet hat. Denn jedes Unix ist schließlich doch ein wenig anders. Damit gibt es heute eigentlich nur noch unixoide Systeme, die man dann logischerweise natürlich auch einfach Unix nennen könnte, da ja alle nicht mehr zu 100% dem entsprechen, was UNIX einmal war. Aber sei's drum. Quelle? Bittesehr: Suche in Google-Bücher. ‣Andreas•⚖ 16:28, 16. Aug. 2018 (CEST)

Das kann man so sehen. Wenn aber (das echte) Betriebssystem "UNIX" heißt und "Unix" nur was ähnliches ist, dann ist die Formulierung "Unix und unixoide" ein Pleonasmus, denn beide Begriffe bezeichnen, Deiner Aussage nach, dasselbe. Also entweder "UNIX-ähnliche" oder "Unix", aber hier geht es ja nicht um Logik, sondern darum, die böse böse Marke UNIX tunlichst zu vermeiden. Vielleicht sollte man überall, wo "VW" erwähnt ist, auch auf "Wolfsburger Auto" verbessern. Zumindest könnte man "Vw" schreiben und damit auch Skoda und sonstwas meinen. --bakunin (Diskussion) 15:17, 18. Sep. 2018 (CEST)

Aus UNIX wurden viele verschiedene Unix. Die waren einmal UNIX, sind nun allerdings abgewichen (geforkt) und wurden zu Unices. Und dann gibt es noch echte unixoide Systeme, also solche, die niemals etwas mit UNIX oder Unix zu tun hatten. Minix und Linux zum Beispiel, das sind unixoide Systeme. Für alle praktischen Belange sind sie Unix-kompatibel, waren aber niemals ein UNIX. Anders BSD: das war mal ein UNIX, ist dann aber zu einem Unix geworden. Und dann gibt es noch die kommerziellen UNICES, die aber auch irgendwie unterschiedlich weiterentwickelt wurden. Heute ist UNIX ein Zertifizierungsprozess, z.B. nach Single UNIX Specification. Zahlt man diesen Kompatibilitätstest und schafft ihn, darf man das System UNIX nennen. Ein Unix oder unixoid ist es ja sowieso. Das berühmteste Beispiel ist wohl macOS, das diese Zertifizierung hat, obwohl BSD (macOS basiert auf Darwin, das in Teilen auf FreeBSD basiert) ja bekanntlich allen UNIX-Code entfernt hat und nunmehr ein Unix ist. ‣Andreas•⚖ 21:43, 18. Sep. 2018 (CEST)

Das ist eine mehr als verkürzte Darstellung der Dinge, die etwa den Lizenzierungsprozeß zu AT&T-Zeiten völlig unterschlägt. Davon abgesehen basiert Darwin auf NetBSD, nicht auf FreeBSD. Was genau ist denn dann ein "Unix oder unixoid", das "es" (was "es"?) "ja sowieso" ist? Hast du irgendeine Definition von dem, was du "Unix oder unixoid" nennst? Solange man mit undefinierten Begriffen durch die Gegend wirft, kann man so ziemlich alles (und das Gegenteil davon) "begründen". --bakunin (Diskussion) 11:24, 22. Apr. 2019 (CEST)

Ja, Darwin hat Teile von FreeBSD, NetBSD, OpenBSD und vielen weiteren Entwicklungen (OPENSTEP, MkLinux, etc...). Der Kernel, XNU, basiert neben Mach aber hauptsächlich auf FreeBSD. ‣Andreas•⚖ 15:56, 22. Apr. 2019 (CEST)

Bezüglich DOS: es gibt DOS im allgemeinen, und es gibt PC-kompatibles DOS. Das wäre dann sowas wie "PC DOS/MS-DOS"oid, wenn du so willst, heißt aber eben "zu PC DOS/MS-DOS kompatibel" oder "IBM-PC-kompatibles DOS". Das ist schon ein Ding, denn auf solchen DOS sind kompatible Programme normalerweise ausführbar. Das trifft auf Apple DOS und Atari DOS und Amiga DOS nicht zu, denn diese DOS sind untereinander und mit PC DOS/MS-DOS nicht kompatibel... ‣Andreas•⚖ 16:32, 16. Aug. 2018 (CEST)

Zu "auf allen Unices gibt es ein Nulldevice:" ja. Natürlich könntest du jetzt sagen: zeig mir zu jedem Unix, dass es ein Nulldevice hat. Aber da finde ich kein Ende, denn ich würde ja niemals wissen, ob ich alle Unices auch gefunden habe. Daher bitte umgekehrt: nenne mir ein einziges Unix ohne Nulldevice! Ich habe kein einziges entdeckt. Bis jetzt. Das wäre wirklich eine Besonderheit... (oder stein-alt?!?) ‣Andreas•⚖ 16:34, 16. Aug. 2018 (CEST)

Darum geht es nicht: Vielleicht hat jedes UIX-ähnliche Betriebssystem ein Nulldevice, vielleicht nicht - ich weiß es nicht, aber ich gehe stark davon aus. Im POSIX-Standard ist die Existenz aber VORGESCHRIEBEN. Jedes richtige UNIX muß also ein Nulldevice haben, jedes UNIX-ähnliche System hat vermutlich eins. Genau diesen Unterschied habe ich explizit beschrieben, aber das darf hier nicht stehen, weil es Vandalismus ist. --bakunin (Diskussion) 15:17, 18. Sep. 2018 (CEST)

Das mag schon sein. Viele verbreitete Unices weichen allerdings von POSIX bewusst ab, zumindest in einigen Bereichen. Dass das Nulldevice in POSIX festgeschrieben ist, wusste ich nicht. Es macht allerdings auch keinen Sinn, keines zu haben. Da es viele Nicht-100%-POSIX-Systeme gibt, aber keines davon kein Nulldevice hat, verstehe ich die Herangehensweise jedoch nicht vollständig. ‣Andreas•⚖ 21:35, 18. Sep. 2018 (CEST)

Ich habe keine Ahnung, was "Unices" bedeutet. Falls das ein Nominativ Plural sein soll: diese Deklination würde nur Sinn ergeben, wenn "Unix" ein lateinisches Femininum der konsonantischen Deklination (zB "radix" "die Wurzel", Pl. "radices") wäre - was es nicht ist. Auch ich kenne einige "Nicht-100%-POSIX-Systeme" (mir fallen nicht allzu viele ein, vielleicht 10) , aber der Unterschied zwischen "ist vorgeschrieben" und "hat vermutlich eins" sollte dennoch evident sein. Es könnte durchaus Sinn haben (wohlgemerkt: haben, nicht machen), auf das Nulldevice zu verzichten - nämlich zum Beispiel dann, wenn Speicherplatz knapp ist das Device nicht gebraucht wird, etwa in Embedded Systems, Microcontrollern, Maschinensteuerungen und dergleichen, wo gerne alle nicht unmittelbar benötigten Kernelteile rausgenommen werden. Ich gehe allerdings aufgrund deiner Aussage "keines davon..." davon aus, daß du die alle kennst, oder? Darf ich dann als Quellenangabe für den Umstand, daß sowieso alles, was nur irgendwie UNIX-ähnlich ist, ein Nulldevice hat, "persönliche Vermutung von Y2kbug" anführen? Deine Begründung, ob sie nun faktisch stimmen mag oder nicht (ich kanns nicht nachprüfen - du vermutlich auch nicht) ist jedenfalls unenzyklopädisch. --bakunin (Diskussion) 00:49, 22. Apr. 2019 (CEST)

Ja, da hast du Recht: meine Aussage ist POV und daher unenzyklopädisch.

Doch worum geht es in dieser Diskussion? Der Diskussionspunkt heißt „Marke UNIX“ – und das ist hier, beim Nulldevice, eigentlich OT – die Diskussion sollte auf Diskussion:Unix stattfinden, nicht hier. Und dazu gibt es ja schon entsprechende Abschnitte, die man dann bekritteln kann, etwa Unix#Der Name Unix (da kommt dann auch Unices neben Unixe und dem englischen Unixes vor) und Unix#Typologie der Varianten.

Was das Nulldevice betrifft: es macht Sinn, dieses allgemein zu erklären, und ich halte es schon für enzyklopädisch, wenn man erwähnt, dass es auf allen Unixen (wenn dir Unices nicht passt) eines gibt. Das ist im allgemeinen eine wahre Aussage. Spezialfälle kann man gerne auch hineinbringen. Aber sich in zu vielen Details zu verlieren wäre auch unenzyklopädisch, oder nicht?

‣Andreas•⚖ 15:56, 22. Apr. 2019 (CEST)

Bezüglich Belege von Messerjokke: ja, das wäre wirklich hilfreich. Und vorher diskutieren auch. Falls Messerjokke hier mitliest: dem möchte ich mich anschließen. ‣Andreas•⚖ 16:36, 16. Aug. 2018 (CEST)

Verbreitung des Nulldevice

Ich beziehe mich hier auf den oben stehenden Text von Y2kbug, irgendwann wird bei noch mehr Einrückungen der Bildschirm zu schmal:

Doch worum geht es in dieser Diskussion? Der Diskussionspunkt heißt „Marke UNIX“ – und das ist hier, beim Nulldevice, eigentlich OT – die Diskussion sollte auf Diskussion:Unix stattfinden, nicht hier.

Es ging hier - das kannst Du ja oben nachlesen - nicht um die Marke UNIX per se sondern es ging darum, daß ich geschrieben habe, daß Betriebssysteme, die diesen Markennamen führen (dürfen), per Vorschrift dazu verpflichtet sind, ein /dev/null zu haben. Das wurde von Messerjokke revertiert und als "Vandalismus" bezeichnet. Ich habe, als ich den Unterpunkt damals aufmachte, "Marke UNIX" lediglich als Stichwort für genau diesen Sachverhalt benutzt, weil ich den vorstehenden Satz nicht als Titel verwenden wollte (ähnlich wie ich das jetzt auch gemacht habe).

Wenn "UNIX" eine Marke ist (also alle Betriebssysteme, die POSIX-zertifiziert sind und sich so nennen dürfen) und "Unix" ein Sammelbezeichnung für alle möglichen Betriebssysteme, die dem ähnlich sind, was dieser Standard darstellt, dann verstehe ich immer noch nicht, warum die Formulierung "UNIX und UNIX-ähnliche" ansstößig sein sollte. Im Gegenteil - aber das alles wurde oben schon ausgeführt - wäre "Unix und Unix-ähnliche" dann ein Pleonasmus (UNIX-ähnliche und solche, die dem Ähnlichen ähnlich sind??). Das hat nichts mit der Diksussion in dem vor Dir angeführten Link zu tun, ich wende lediglich die Ergebnisse dieser Diskussion hier an - aber selbst das führt zum Vorwurf "Vandalismus".

Es geht nämlich - zumindest habe ich das Gefühl - Messerjokke und seinesgleichen überhaupt nicht darum, irgendwas zu definieren, sondern sie verfolgen mit dem heiligen Eifer des Fanatikers jede Nennung der ach so bösen Marke "UNIX", weil das nicht in ihr Denkschema von "erstmal war nichts - und dann hat Linus Torvalds Linux erfunden" paßt.

Was das Nulldevice betrifft: es macht Sinn, dieses allgemein zu erklären, und ich halte es schon für enzyklopädisch, wenn man erwähnt, dass es auf allen Unixen (wenn dir Unices nicht passt) eines gibt. Das ist im allgemeinen eine wahre Aussage.

Was soll eine "im allgemeinen wahre Aussage" sein?? Stimmt das immer, außer in Schaltjahren? Eine Aussage ist entweder wahr oder falsch und in beiden Fällen kann man Belege dafür bringen. Tut mir leid, aber das, was du da vertrittst, ist lediglich eine Vermutung, außer du kennst alle UNIX- und UNIX-ähnlichen Systeme. Wenn das der Fall ist: Beleg rein und die Diskussion ist beendet. Mit "unenzyklopädisch" habe ich genau das gemeint: wir schreiben hier keine Einführungsliteratur zum Thema "wie verwende ich ... für Anfänger und Unbedarfte", sondern eine Enzyklopädie. In anderen (nicht-Unix-) Artikeln wirst du auch keine "im allgemeinen wahren" Aussagen finden - und oft genug steht ein Baustein dort, wo Belege reklamiert werden. Es ist mir egal, was genau in dem Artikel steht (im Sinne von: mir ist ein bestimmter Inhalt nicht lieber als ein anderer), aber das, was dort steht, sollte belegbarer Fakt sein, nicht nur eine Vermutung a la "naja, ich kenn keins, das anders ist". Die Wikipedia soll - laut eigener Aussage - "das Wisssen der Welt [...] widerspiegeln". Wohlgemerkt: das Wissen, nicht alle mehr oder weniger gesicherten Vermutungen. --bakunin (Diskussion) 22:51, 22. Apr. 2019 (CEST)

POSIX ist ein theoretischer Standard, der von Betriebssystemen mehr oder weniger umgesetzt wird. Wie du selbst schreibst, ist ein UNIX-Betriebssystem denkbar, das das Nulldevice absichtlich weglässt und somit nicht mehr POSIX-compliant wäre. Das kann ich aber nicht nachprüfen, da der POSIX-Standard nicht frei verfügbar ist. Das mit dem Belege bringen ist also nicht so einfach wie von dir dargestellt. Aber bitte – bring einen Beleg, dass das Nulldevice im POSIX-Standard steht. (Hier kann man POSIX 1003.1-2017 kaufen...)

POSIX ist aus dem UNIX-Betriebssystem heraus entstanden, nämlich als Notwendigkeit, UNIXe ("Unices") untereinander kompatibel zu halten. Denn in den 1980er-Jahren entstanden ganz ganz viele verschiedene UNIX-Derivate, die teilweise später vom ursprünglichen AT&T-UNIX-Code gesäubert wurden – das urspüngliche BSD zum Beispiel, die Basis von FreeBSD, NetBSD und OpenBSD. Die Laufrichtung ist also UNIX → POSIX, denn POSIX beschrieb ursprünglich ein existierendes UNIX-Betriebssystem.

POSIX ist aber nicht mehr nur Unix. Denn auch andere Betriebssysteme sind zu bestimmten POSIX-Standards kompatibel, so etwa Windows NT von Beginn an (psxss.exe und psxdll.dll, siehe POSIX and UNIX Support in Windows).

So gut wie jedes Unix dürfte POSIX-kompatibel sein – oder absichtlich in (wenigen) Details vom POSIX-Standard abweichen.

Was heißt UNIX und UNIX-ähnlich? Es heißt, dass UNIX (von dem der POSIX-Standard abgeleitet ist), also ein direkter AT&T-UNIX-System-V-Abkömmling wie SGI IRIX, SCO UnixWare oder Sun Solaris, und andere UNIX-artige Betriebssystem wie BSD (das keinen UNIX-Code mehr enthält, aber zu UNIX kompatibel ist) oder Minix (das nie ein UNIX war, aber dennoch Unix-kompatibel ist) oder Linux (ditto) im Regelfall ein Nulldevice besitzen. Soweit stimme ich also mit dir überein. Aber mit Bezug auf WP:OMA kann man das auch anders schreiben, eben Unixoides System und Unix, weil es genau so schon in der Wikipedia steht, z.B. in der Liste von Unix- und Unix-ähnlichen Betriebssystemen. Hier jetzt plötzlich „UNIX und UNIX-ähnlich“ zu verwenden, das führt neue Betriffe ein, die so in den anderen existierenden Aritkeln nicht abgebildet sind.

UNIX → Unix, UNIX-ähnlich → unixoides System, und alles ist gut.

Und was die im allgemeinen wahre (=zutreffende) Aussage betrifft: meinst du nicht, dass Unix und unixoide Systeme normalerweise /dev/null besitzen? Wenn das nämlich strittig ist, dann kannst du nur noch schreiben, dass POSIX-konforme Systeme ein /dev/null als Nullgerät besitzen. Und das darfst du dann bitte auch belegen. Das POSIX-konforme Windows NT hat ein Nullgerät, ich bezweifle aber, dass es dort /dev/null heißt. Viel Spaß!

‣Andreas•⚖ 00:44, 23. Apr. 2019 (CEST)

Nachtrag: Ich habe mir die Freiheit genommen, die Einleitung zu überarbeiten.

Außerdem habe ich diese Diskussion auf GitHub gefunden, bei der es um /dev/null unter Windows NT geht... ‣Andreas•⚖ 01:12, 23. Apr. 2019 (CEST)

Ob Windows (bzw., damit wir die Marke Windows vermeiden, "WiNdOwSoale Systeme", also Systeme die entweder Windows sind, so aussehen die gleiche Verpackung haben oder sonst irgendeine Ähnlichkeit aufweisen) ein /dev/null oder irgendein anderes Nulldevice hat, ist hier wohl unerheblich.

Außerdem gehst du schon von falschen Voraussetzngen aus, denn POSIX ist mitnichten ein "theoretischer Standard", sondern ein praktisch (von einigen Systemen) umgesetzter. Darüber hinaus ist der POSIX-Standard keineswegs "nicht frei verfügbar", sondern offen einsehbar. Ich habe ihn als Quelle verwendet und direkt daraus zitiert. IM ÜBRIGEN HABE ICH DIE VORSCHRIFT BELEGT, daß POSIX ein /dev/null vorschreibt und das als Quelle in dem Artikel genau so angeführt, siehe [Version]. Also jetzt daherzukommen und von mir Belege zu verlangen, nachdem man mit Vermutungen und "im allgemeinen wahren Aussagen" herumhantiert und dann genau den Beleg entfernt hat, den man nun fordert, ist schon reichlich merkwürdig. Da in GitHub jeder schreiben kann, was er will, ist das wohl kaum eine reputable Quelle. In der deutschen Wikipedia findest du jede Menge Diskussionen, wo selbst anderssprachige Wikipedias als Quelle abgelehnt wurden, weil eben jeder schreiben kann, was er will und die Peer Review nicht sichergestellt ist. Wenn das so ist, dann ist GitHub erst recht keine Quelle. --bakunin (Diskussion) 07:08, 23. Apr. 2019 (CEST)

Nachtrag: ich habe mir die Freiheit genommen, die Überarbeitung zu überarbeiten. --bakunin (Diskussion) 21:09, 23. Apr. 2019 (CEST)

Erstmal danke für deine Inputs. Oder sollte ich sagen DANKE FÜR DEINE INPUTS. ;-)

Ich habe deine Verlinkung von POSIX und dem darin vorgeschriebenen /dev/null ja nicht aus dem Artikel gelöscht, oder? Ich habe es auch nicht bezweifelt, dass es dort so steht.

Danke für deine Beiträge bei dieser Diskussion – dass POSIX nicht mehr bezahlt werden muss, wusste ich nicht. Es war früher immer wieder zu lesen, dass der Standard gekauft werden müsste ("Paywall"). Inzwischen habe ich herausgefunden, dass der IEEE-Standard 1003.1, in der aktuellen Version IEEE 1003.1-2017, nicht nur frei verfügbar ist, es ist in Wirklichkeit POSIX. Eine weitere Bezeichnug ist offenbar ISO/IEC 9945.

Seufz - hier zum gefühlt tausendsten Mal: "POSIX" mußte nie bezahlt werden und der Standard war immer einsehbar. Die Zertifizierung, daß ein gegebenes System tatsächlich dem POSIX-Standard entspricht, mußte bezahlt werden (und das muß sie immer noch). --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

Windows NT ist POSIX.1-konform, genauer: Windows NT 4.0 ist zu ISO/IEC 9945-1:1990/IEEE Std 1003.1-1990 kompatibel, also zum POSIX-Standard von 1990. Das ist Fakt.^{Microsoft TechNet}

Ich habe den Umstand nicht bezweifelt, lediglich dessen Relevanz. 1990 ist immerhin fast 30 Jahre her und der POSIX-Standard von damals hat mit dem von heute nichts mehr zu tun. (Um es ganz genau zu sagen: "nichts" für hinreichende Werte von "nichts".) --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

Wenn du also immer wieder von POSIX sprichst, was meinst du dann eigentlich genau? UNIX?

Nein, ich meine "POSIX". "UNIX" darf sich ein System (genauer: eine konkret vorliegende Version eines Systems) dann nennen, wenn es den (aktullen) POSIX-Standard erfüllt und die (siehe oben: kostenpflichtige) POSIX-Zertifizierung besteht. "UNIX" ist eine Marke und das Recht, diese Marke zu führen, ist an diese Voraussetzungen gekoppelt (und einige andere, die aber technisch nicht so relevant sind wie diese). Du kannst - nur zum Vergleich - auch das Recht erwerben, Coca-Cola in Flaschen abzufüllen, aber du darfst das nur dann "Coca Cola" nennen, wenn dir die Firma (wer auch immer Coca Cola besitzt, ich trinke keins), die die Marke besitzt, erlaubt, dies zu tun - und deren Erlaubnis wird vermutlich (unter anderem) davon abhängen, daß das, was du da einfüllst, auch das ist, was sie unter "Coca Cola" verstanden haben wollen. In gewisser Weise kann man also "POSIX" und "UNIX" durchaus synonym verwenden und in diesem Sinne habe ich es getan. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

Wenn du UNIX meinst, dann meinst du nicht POSIX, sondern genau genommen SUS, also die Single UNIX Specification (aktuell: Version 4, 2018).^{opengroup.org}

Und nochmal: Sogut wie jedes Unix (also auch ein Unix oder unixoides System, das nicht nach SUS spezifiziert ist und daher nicht UNIX, in Großbuchstaben, heißen darf) hat /dev/null

Erstens - siehe oben. Zweitens: nein, "jedes unixoide System" muß eben kein /dev/null haben und vermutlich gibt es einige Implementationen im Embedded-Systems-Bereich, bei denen genau das der Fall ist. Die sind dann durchaus "UNIX-ähnlich", aber eben nicht POSIX-kompatibel (weder zertifiziert, nocht sonstwie). Ich bin schon zu lange aus der Programmierung von Microcontrollern raus, als daß ich das sinnvoll beurteilen könnte. Zu meiner Zeit (aber das ist nun schon über 20 Jahre her, daß ich solche Schen gemacht habe), hat man das durchaus hin und wieder gemacht, daß man den Kernel und die libc auf genau das, was man tatsächlich gebraucht hat, 'runtergestrippt hat, um noch ein paar Bytes für nicht genutzte Kerneltabellen und dgl. zu sparen. Ich gehe davon aus, daß man das heute auch noch tut, aber ich weiß es eben nicht genau. Du aber weißt es - das geht zumindest aus deinen Einlassungen hervor - auch nicht genau und deshalb sollte man sich hier auf das beschränken, was man belegen kann und nicht das anführen, was wahrscheinlich so oder so ähnlich ist. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

, obwohl es strickt genommen dadurch in diesem Punkt dennoch POSIX-konform ist und dieses virtuelle Gerät gemäß diesem Standard umsetzt. Andererseits haben wir ein POSIX-konformes Betriebssystem wie Windows NT 4.0 oder Plan 9, bei dem zumindest ersteres zwar ein Nullgerät hat, aber nicht /dev/null. (Plan 9 kenne ich leider nicht, aber es ist ebenfalls POSIX-konform, ohne ein UNIX oder Unix zu sein!)

Also erstens: wodurch sollte diese POSIX-Konformität von Plan 9 belegt sein? Mir wäre davon nichts bekannt. Davon abgesehen ist Plan 9 kein Betriebssystem, sondern der Entwurf zu einem solchen - das eigentliche System wartet seit Jahrzehnten auf die Fertigstellung bzw. Veröffentlichung. Zweitens - irgendein WindowsNT war irgendwann mal zu einer sehr, sehr alten Version des POSIX-Standards kompatibel. Na, wenn schon! Irgendwann mal waren "deutsche Autos" hauptsächlich Zweitakter (nämlich, als man unter "Deutschland" auch die DDR verstehen konnte und dort "deutsches Auto" hauptsächlich "Trabant" meinte), aber dennoch willst du das bestenfalls als historische Anmerkung in einen Artikel "deutsche Autos" einbringen, aber sicher nicht in der Form "deutsche Autos sind meistens Zweitakter".

Kritik zu deiner Änderung:

• Ein Device? Das deutsche Wort dafür ist „Gerät“...

Nein, ist es nicht. Das Wort "device" bedeutet eben nicht nur "Gerät" sondern alles Mögliche: A mathematician is a device for turning coffee into theorems. Glaubst du, der Mathematiker sei ein "Gerät"? The progressive form is a language device for expressing ....: Glaubst du im Ernst, da ist ein "Sprachgerät" gemeint? Nur deshalb, weil dieser Unsinn verbreitet ist, wird er deshalb nicht richtiger. Nur deshalb, weil alle von "Sinn machen" reden, gibt es diese Form im Deutschen noch lange nicht (sondern zB. nur "Sinn haben"). --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• • Und warum ist /dev/null deiner Meinung nach kein virtuelles Gerät?

Weil es eben kein Gerät ist - weder ein "virtuelles" noch ein anderes. Ein Kinderwagen ist auch kein Rasenmäher, auch kein "virtueller Rasenmäher". Tatsächlich ist /dev/null ein Satz von Betriebssystemcalls, die als Zugriffspunkt eine Datei haben, weil das unter UNIX so üblich ist - everything is a file. Dasselbe gilt, mutatis mutandis, für /dev/random und auch einige andere device files. Diese "device files" sind aber die unter UNIX üblichen "Kunstgriffe" (devices), die dadurch implementierten Services allgemein zur Verfügung zu stellen. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• …das in vielen Betriebssystemen als Ziel zu entsorgender Datenströme fungiert?
  • Du beschreibst hier den Schreibvorgang in ein Nullgerät. Das ist aber nur die halbe Wahrheit. Das Nullgerät, im vorliegenden Fall das unter Unix gebräuchliche /dev/null, ist aber auch eine (virtuelle) Datei, die gelesen werden kann. Warum so WP:POV (gefärbt)?

Ich kann den POV nicht erkennen. Du erkennst doch sicher den Unterschied zwischen "X ist ..." und "X fungiert als ...", ja? Daß es auch gelesen werden kann, habe ich erstens nicht bestritten, sondern nur in diesem einen Satz nicht erwähnt - wie viele andere Dinge, die in dem Artikel auch stehen, aber in dem einen Satz auch nicht vorkommen. Zweitens habe ich nicht gesagt, daß es keine Datei ist - ich ahbe gesagt "es fungiert als". Wenns dir besser gefällt: es ist eine Datei, die als ... fungiert (unter anderem).

• • Die Nutzung in Datenströmen ist aber auch wieder nur eine Möglichkeit, das Nullgerät zu verwenden. Gemäß dem Unix-Motto „Alles ist eine Datei“ kann man es (fast) wie jede andere Datei verwenden, die gelesen und kopiert werden kann. Es sei denn, du verstehst auch Dateien als Datenströme, aber die bereits existierenden Artikel Datenstrom und Gerätedatei passen als Unterscheidung wohl besser. Dateien sind keine Datenströme, aber man kann den Inhalt von Datein in einen Datenstrom packen und umgekehrt.

Erstens: den Unterschied zwischen "Datenstrom" und "Datei" mußt du mir erklären - den gibt es nämlich - jedenfalls unter UNIX - nicht. Jede Umleitung zeigt dir das, denn das, was umgeleitet wird, ist ja ein Datenstrom und wenn es danach nicht mehr irgendwo im Hauptspeicher sondern auf einer Platte steht, hat sich an seiner grundlegenden Eigenschaft nichts geändert.

Tatsächlich kann man /dev/null nicht nur fast wie jede andere Datei verwenden - man kann es ganz genau so wie jede andere Datei verwenden, weil es nämlich eine Datei ist. Die Datei ist insofern speziell, als sie in /dev angesiedelt ist und - per inode - als character-orientiertes device file gekennzeichnet ist, aber diese Eigenschaft teilt es mit vielen anderen Dateien, die ähnlich funktionieren. Daß es ein characer-orientiertes File (und kein block-orientiertes)ist, bedeutet, daß bestimmte Zugriffsmethoden (ftell(), fskip(), ...) besonderen Regeln und Einschränkungen unterworfen sind, aber auch das rührt nicht von der Eigenschaft "Datei", sondern von der Eigenschaft "character-orientiertes device" her und ist bei jedem anderen Filesystem-Eintrag mit dieser Eigenschaft genau so. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• • • Und ganz genau genommen meinst du nicht Datenströme, sondern die Umleitung von Datenströmen. Das ist unter Unix etwa soetwas wie cat /dev/random > /dev/null (was ziemlich sinnlos wäre), aber auch die Umleitung per Pipe (Informatik).

Sorry, aber "die Umleitung von Datenströmen" ist eine Leistung der Shell und hat nichts mit den Zielen einer eventuellen Umleitung zu tun. Ja, man kann aus /dev/null lesen, aber auch das ist die Erzeugung eines Datenstroms (der in dem Fall aus lediglich EOF besteht), den man dann weiterverarbeiten (umleiten, ...) kann.

• • Summa summarum: Mit dem Satz „als Ziel zu entsorgender Datenströme“ beschränkst du das Nullgerät auf höchsten 50% (Datenstrom vs. Datei) von 50% (schreiben vs. lesen), also 25% dessen, was /dev/null in Wirklichkeit mindestens ist. Ein WP:NPOV (neutraler Standpunkt) wäre hier besser!

Tu ich eben nicht. Aber da ich in theoretischer Informatik nicht sonderlich gut beschlagen bin (ich seit 40 Jahren SysAdmin und Softwareentwickler, mit den theoretischen Aspekten beschäftige ich mich kaum), schlage ich vor, wir machen es etwas einfacher: sag mir doch einfach, welche Verwendung nicht durch meine Formulierung "Ziel von ... Datenströmen" abgedeckt ist. Beispiele reichen. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• …seine Existenz für UNIX-Systeme vorgeschrieben…
  • Warum nutzt du dann den POSIX-Standard als Quelle/Beleg, wenn du eignetlich UNIX (also SUS) meinst? Nochmal: Windows NT (4.0) und Plan 9 sind POSIX-konform und kein UNIX.

?? Wie bitte? Ich habe audrücklich geschrieben, daß seine Existenz für UNIX-Systeme vorgeschrieben ist, wieviel ausdrücklicher soll ich denn "UNIX" meinen? Da aber - siehe oben - ein UNIX-System sich nur "UNIX" nennen darf, wenn es den POSIX-Standard erfüllt (unter anderem), ist das, was dort drin steht, sehr wohl relevant und als Beleg geeignet. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• • Warum lässt du Unix-Betriebssysteme wie *BSD, Linux, Mac OS X (vor 10.5) außen vor? Auch die haben alle /dev/null!

Den Nachweis dafür hast du immer noch nicht erbracht. Gib doch einfach einen Beleg dafür an und gut ist. Und wenn du dafür keinen Beleg hast, dann ist das eben eine - mehr oder weniger gesicherte - Vermutung, nicht mehr. Außerdem habe ich nichts "außen vor" gelassen, denn ich habe "UNIX-ähnliche" ausdrücklich erwähnt - so lange, bis ich das nicht mehr sagen sollte, darum steht da jetzt "viele Betriebssysteme" - worin UNIX-ähnliche durchaus enthalten sind, oder nicht? Ich habe ja auch von "UNIX" als Sammelbegriff gesprochen und AIX, HP-UX, Tru-64, Solaris, SunOS, SCO und was es sonst so alles gibt, nicht ausdrücklich erwähnt. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• • Du selbst hast gesagt, dass es Unix-Systeme geben könnte, bei denen man /dev/null einfach weglässt. Meist du, dass ein UNIX, bei dem man /dev/null entfernt (als root, also SysAdmin, kann man "character special files" bzw. virtuelle Gerätedateien auch löschen^{hier ein Bsp. unter AIX}, somit beim Betriebssystemstart auch weglassen oder wegkonfigurieren), kein UNIX mehr ist? (Aw: Doch, es bleibt ein UNIX.) Ist es dann auch nicht mehr POSIX-konform? (Aw: nein, dann ist dieses spezielle System nicht mehr POSIX-konform.)

Ich verstehe nicht, was du mit diesen Gedankenspielen erreichen willst. Ich habe gesagt (und auch belegt) daß ein UNIX-System ein /dev/null haben muß (wohlgemerkt, "UNIX" großgeschrieben). Daß es "Unix"- (kleingeschrieben, also, wenn ich das formulieren sollte: "UNIX-ähnliche") Systeme geben kann, die das nicht haben (und deshalb - nebst möglichen anderen Gründen - auch kein UNIX sind), steht dem nicht entgegen. An den von dir angeführten Thread kann ich mich erinnern, weil ich selbst daran beteiligt war: es war in der Tat einige Zeit lang so (rund um AIX 5.3, gefixt wurde das, wenn ich mich recht erinnere, in irgendeinem TL von 6.1), daß die IBM-Installationsskripte buggy waren (etwa die CAS-Installation) und ein File "/dev/null 2>&1" angelegt haben (siehe auch hier, weil die Herren Scriptprogrammierer bei IBM keine Ahnung von Shell zu haben scheinen). Da aber die Zertifizierung eines Betriebssystems nicht auf irgendeiner Installation, auf der man alles mögliche herumkonfiguriert hat, durchgeführt wird, sondern auf einer Standardinstallation, ist das hier kaum relevant. Ja, wenn du darauf bestehst: wenn das /dev/null gelöscht wird, ist das System nicht mehr UNIX, weil nicht mehr POSIX-zertifizierbar. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• • Also nochmal: Wenn man die gerade erörterten Punkte im Hinterkopf behält, ist in diesem Zusammenhang UNIX und Unix gleichbedeutend. Auch POSIX ist nur insofern relevant, als dass /dev/null dort vorgeschrieben ist. Aber auch nicht zu 100% POSIX-complient Unices haben /dev/null (wenn root es nicht löscht... aber man kann es mit mknod auch jederzeit erstellen), weshalb "Unix-Betriebssysteme" in diesem Artikel richtiger ist als "UNIX-Systeme".

Aha. Laß mich mal raten: Bei Autos ist das Vorhandensein eine Sicherheitsgurts vorgeschrieben. Es gibt aber andererseits auch Kinderschaukeln, die ebenfalls einen Sicherheitsgurt haben. Aus dem Grund sollte aus dem Artikel "Sicherheitsgurt" der Hinweis, daß er in Autos vorgeschrieben ist, entfernt werden, weil ja nicht nur Autos einen haben können. Der Unterschied zwischen können und müssen ist dir aber schon geläufig, oder? --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• „Darüber hinaus wird - abhängig vom verwendeten Filesystem - der Inode-inhalt geändert, weil die atime neu gesetzt wird.“
  • Ja^{* (nur im allgemeinen bzw. vereinfacht gesehen richtig)}. Aber was hat das mit dem Nullgerät zu tun?
  • Das deutsche Wort für Filesystem (englisch eigentlich auch "file system" mit Leerzeichen) ist Dateisystem. Bitte verwende das deutsche Wort. Wir sind ja auch auf der deutschen Wikipedia.

Das Wort "Dateisystem" ist genausowenig deutsch wie "filesystem" (mit oder ohne Spatium), da ist nur das (englische) Fremdwort durch zwei andere (ein lateinisches und ein griechisches) ersetzt. Und da wir in der deutschen Wikipedia sind, sollten wir besser von "Sachverhaltsdarstellungsansammlungsanordnung" reden, oder? --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• • ^*Es gibt auch Dateisysteme mit atime, die keine Inodes verwenden. (Beispiel: ReiserFS 3 verwendet keine Inodes, bietet aber accesstimes.)
  • ^*Dateisysteme mit oder ohne Inodes könnten per mount-Option auch ohne Änderung der accesstime genutzt werden (mount-Option noatime für Dateien bzw. nodiratime für Verzeichnisse). Es hängt also nur bedingt vom Dateisystem ab, mehr schon von dessen Implementierung und von den Möglichkeiten des Betriebssystems (oder, genauer, des Kernels des Betriebssystems).
  • Aber das hat alles nichts mit /dev/null zu tun...

Das hat insofern was mit /dev/null zu tun, als das angeführte Beispiel cat /path/to/file > /dev/null (oder so ähnlich) die atime ändert - das habe ich geschrieben. Zugegeben, natürlich nur dann, wenn das Filesystem überhaupt eine atime unterstützt und die Änderung erfolgt auch nur dann im Inode, wenn es ihn gibt, ansonsten in der entprechenden Struktur. Aber ob es die atime ändert oder nicht ist - eben IN ABHÄNGIGKEIT VOM FILESYSTEM (bedeutet in diesem Zusammenhang auch: wie es gemountet ist, weil die Art des Mounts ja auch eine Eigenschaft des (konkreten) Filesystems ist) - so. Das ist nicht "vereinfacht" richtig (deshalb habe ich ja die Gültigkeit der Aussage entsprechend eingeschränkt), sondern einfach: richtig. Sollen wir es auf eine Formulierung ändern die "im allgemeinen eine wahre Aussage" darstellt, wie du das weiter oben formuliert hast? Auf der einen Seite sagst du: "Aber sich in zu vielen Details zu verlieren wäre auch unenzyklopädisch, oder nicht?" (22. April) und jetzt willst du die Aussage nicht nur allgemein unter Hinweis auf das verwendete Filesystem einschränken, sondern - was? ReiserFS v3 ausdrücklich erwähnen? Ich habe seit mehr als zehn Jahren kein System mehr gesehen, das ReiserFS übehaupt verwendet und wirklich verbreitet war es sowieso nie. Was genau verstehst du denn unter "Details", in die "man sich nicht verlieren" sollte? --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

• • Mit einer Umformulierung, die etwas neutraler ausfällt (WP:NPOV), könnte man es trotzdem im Artikel lassen...

Was genau ist denn daran POV? --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

Zusätzlich könnte man noch dazuschreiben, dass es unter Linux normalerweise eine "special character file" (deutsch: virtuelle Gerätedatei) mit major 1 und minor 3 ist, siehe z.B. die manpage (auch hier) oder hier.

Da habe ich nichts dagegen, aber ich verstehe nicht ganz, was du mit "neutraler" meinst: wenn du dir viele andere einschlägige Artikel ansiehst, dann wirst du feststellen, daß oben zwar "Unix" stehe, im Weiteren aber so getan wird, als ob das nur Linux wäre und alles andere unter den Tisch fallen gelassen werden kann. Dazu dann noch ein Bildchen mit einem Screenshot von KDE (siehe etwa Gerätedatei mit Bildchen von Konqueror). Wenn man einen Linux-Artikel haben will, dann soll man auch "Linux" draufschreiben und wenn du einen Artikel /dev/null (Linux) anlegen willst, dann habe ich nichts dagegen. Die Wikipedia kennt keine Beschränkung hinsichtlich der Anzahl der Seiten und wenn man schon einen eigenen Artikel für jeden vor 1825 stillgelegten Regionalbahnhof haben muß, dann kann man auch ein paar IT-Artikel haben. Aber oben "Unix" hinzuschreiben und dann so zu tun als wäre das, was bei GNU ("..NOT UNIX"!!) geschieht, der Normalzustand, das ist einfach Etikettenschwindel. Im Artikel "Auto" werden schließlich auch nicht zuallererst und vorzugsweise die Erzeugnisse von Matchbox beschrieben (obwohl es die auch gibt), sondern richtige Autos.

Noch was: mit "major 1 und minor 3" meinst du vermutlich die major number und minor number. Da du dich über die verwendeten Fremdworte echauffiert hast, sollte das doch "größere Zahl und kleinere Zahl" heißen, oder? Also (alle Fremdworte raus): "Unter Linux ist /dev/null eine besondere nichtwirkliche Gerätesachverhaltsdarstellungsansammlung, die die größere Zahl 1 und die kleinere Zahl 3 haben muß." Gibs zu, das ist viel besser verständlich, nicht? ;-)) --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

ÜBRIGENS: Laut BSD's NULL manpage (auch z.B. in Apple's OS X 10.9 NULL manpage!) ist das Nullgerät /dev/null das allererste Mal in AT&T UNIX Version 7 aufgetaucht... Das sollten wir wohl auch noch in den Artikel aufnehmen...

Von mir aus, warum nicht? Ich habe ja nicht gesagt, daß der Artikel nicht erweitert werden sollte. Bei der angegebenen Quelle hätte ich immerhin die Bedenken, daß das Informationen aus zweiter Hand sind und man die Dokumentation für v7 konsultieren sollte. Aber Schwamm drüber. --bakunin (Diskussion) 11:16, 26. Apr. 2019 (CEST)

Ich warte jetzt aber doch mal deine Antwort auf meine Kritik ab. Ändern kann ich die Kritikpunkte sonst später immer noch...

‣Andreas•⚖ 21:21, 24. Apr. 2019 (CEST)

Danke für deine ausführliche Antwort. Du hast viele gute Punkte.

Zu den Anglizismen muss ich sagen, dass ich kein Freund davon bin. Es gibt deutsche Worte, auch wenn sie dir nicht gefallen mögen, und deren Bedeutung kann natürlich nicht immer mit den englischen Begriffen mithalten. Device könnte so ein Wort sein.

• Wenn es stimmt, dass /dev/null, /dev/random usw. keine virtuellen Geräte sind, dann ändere doch bitte auch gleich Artikel Gerätedatei, Abschnitt Virtuelle Gerätedateien, denn dort steht es genau so.

Tut mir wirklich leid, aber das werde ich nicht tun. Ich war mal einige Zeit deutlich aktiver in der Wikipedia, aber die ständigen Streitereien mit selbsternannten "Experten", deren Qualifikation im Runterladen einer Ubuntu-Live-CD besteht, habe ich gründlich satt. Leute die sich berufen fühlen, Rob Pike, Brian Kernighan und mich darüber zu belehren, was eigentlich "Unix" ist und daß es, wenns kein Linux ist, "schrecklich veraltet" sein muß (siehe wortwörtlich die Diskussion hier) haben mir die Lust zur Mitarbeit gründlich ausgetrieben. Ich bin ein ziemlich guter Systemadministrator, aber in der Rolle des Manns von La Mancha eine Fehlbesetzung. Aus dem Grund beschränke ich mich ausschließlich auf Artikel mit UNIX-Relevanz. Das sind insbesondere solche, die in die Kategorie Unix-Betriebssystemkomponente aufgenommen werden können. Für mehr - und insbesondere die Auseinandersetzung mit der geballten Ignoranz - ist mir meine Zeit zu schade. Wenn du die Änderungsgeschichte der Artikel, die cih hauptsächlich geschrieben habe, nachverfolgst, wirst du zum Beispiel feststellen, daß Messerjokke79 sich einen Sport daraus macht, Fußnoten und Belege, die ich eingefügt habe, möglichst ersatzlos wieder rauszunehmen. Ich eigne mich nicht nur als gegen Windmühlen kämpfender Don Quixote nicht gut, ich mach auch als Sysiphos eine schlechte Figur. --bakunin (Diskussion) 13:20, 28. Apr. 2019 (CEST)

Eine Quelle habe ich dazu nicht. Noch nicht. Es sollte aber klar sein, dass einige der englischen Begriffe ins Deutsche übersetzt wurden (und werden). Gerade dann, wenn es entsprechende Artikel in der Wikipedia bereits gibt, ist es – finde ich – ratsam, diese auch zu verwenden. Ich persönlich mache es oft so, dass ich den englischen Begriff ebendfalls aufnehme und ihn mit dem deutschen Begriff gleichsetze, bei der ersten Erwähnung, und im Text dann hauptsächlich den deutschen Begriff weiterverwende. Aber das ist Geschmacksache. Manchmal kommt auch das eine oder andere Mal noch der englische Begriff vor.

Mit der Übersetzung von Fachbegriffen ist es halt so eine Sache: glaubst du, daß es einen Grund dafür gibt, warum die Mediziner von "Luxation" (und nicht von "Umrichtung", das ist die deutsche Übersetzung) reden? Warum Matemathiker von "Homologie" (und nicht etwa "Gleichartigkeit" oder dergleichen) reden? Es geht hier ja gar nicht um "Fremdworte" - sonst würde auch das "Dateisystem", das aus dem lateinischen "Datum" und dem griechischen "Σύστημα" gebildet wird, auch darunter fallen. Man dürfte nicht mal "Büro" (frz. "bureau") sagen. Tatsächlich, wenn hier tränenreich die Häufigkeit von Fremdworten beklagt wird, dann sind ausschließlich (englische) Fachworte aus der Informatik gemeint, worüber sich Leute in Meetings, die sie in ihren Workgroups abhalten, beim Breakfast Huddle ärgern, kurz bevor sie einen complaint posten. Also: entwder Fremdworte raus - dann aber bitte alle, was uns zum Viertaktvierbummszerknalltreibling (ja, den gabs mal) bringt ODER wir akzeptieren, daß die EDV, wie jedes andere Fachgebiet auch - seine Fachsprache hat, die wir uns nicht von anderen aus der Hand winden lassen. Schon gar nicht von so "reputablen" Quellen wie der ComputerBild, die den Unsinn mit den "Gerätedateien" überhaupt erst aufgebracht haben. Sieh dir meine Benutzerseite an, da habe ich schon begonnen, Hilfestellungen für Verdeutschungsfachleute zu sammeln. --bakunin (Diskussion) 13:20, 28. Apr. 2019 (CEST)

Nachtrag: Tatsächlich ist die Sache speziell mit den "Geräten" so: für das, was sich unter UNIX und ähnlichen OSen üblicherweise im /dev-tree findet, gibt es in den meisten (nicht-UNIX-ähnlichen, etwa z/OS, VMS, ....) einen Satz von Systemcalls. Diese Systemcalls gibt es etwa auch in DOS und seinen Abkömmlingen, wo zum Beispiel der von dir erwähnte "COM-Port" (vermutlich meinst du eine serielle Schnittstelle) nicht über eine Datei, sondern per "COMn:", die Centronics-schnittstelle als "LPTn:" usw. angesprochen wird. In JCL (Job Control Language) wird ebenfalls streng zwischen Dateien und sonstigen Einrichtungen unterschieden. Diese Betriebssysteme unterscheiden alle zwischen Datenströmen (salopp gesagt, das, was Programme so erzeugen) und deren Destination. Lediglich UNIX (und seine Abkömmlingen) erhebt es zu Bauprinzip, diese Systemcalls mit einem Zugriffspunkt im Filesystem zu versehen, indem irgendwo im /dev-Tree eine Datei angelegt wird (mit Inode und allem, was eine Datei auszeichnet), über den dann diese Systemcalls abgewickelt werden. Am Beispiel /dev/random: auf einem "normalen" System hast Du lediglich einen Treiber, der (meistens) aus Hardware-Interrupts Zufallszahlen erzeugt und damit /dev/random mit Entropie füllt. Anstatt nun - wie in anderen Betriebssystemen - Funktionen wie getRandom(), etc. zu haben, kann man unter UNIX einfach /dev/random auslesen, der Treiber wird dann entsprechend (zur Erzeugung weiterer Zahlen) angetriggert. Es gibt auch Systeme, die echte (Hardware-)Zufallsgeneratoren haben. Die füllen dann aber ebenfalls Daten in /dev/random ein und Anwendungsprogramme brauchen sich um den Unterschied nicht zu kümmern. Das besondere an UNIX und seinem Bauprinzip ist nun nicht, daß für Anwendungsprogramme der Zugriff derselbe ist - das wäre er bei Systemcalls auch - sondern, daß schon die unterschiedlichen Treiber (Hardware-, Software-RPG) auf dem selben API (nämlich dem Dateisystem und einer Datei) aufsetzen. Das (und nicht Umleitungen oder Pipes) ist mit "alles ist eine Datei" gemeint. Das hat, neben unbestreitbaren Vorteilen, durchaus auch Nachteile: die Interprozeß-Kommunikation wird ebenfalls über das Filessystem abgewickelt (FIFOs), was die Sache zum Teil reichlich schwerfällig und unübersichtlich macht, verglichen etwa mit den ensprechenden Einrichtungen in OS/370 und seinen Verwandten. Aber das nur nebenbei. --bakunin (Diskussion) 14:01, 28. Apr. 2019 (CEST)

• Wenn ich mir die Artikel Datei und Datenstrom ansehe, dann sehe ich schon einen Unterschied. Ein Datenstrom kann auch von einem Gerät zum anderen direkt erfolgen. Ein Beispiel, das mir einfällt, ist etwa eine im Arbeitsspeicher stattgefundene Berechnung, die direkt an ein COM-Port (oder ein USB-Gerät, oder was auch immer) geleitet wird. Da ist dann keine Datei involviert. Da aber unter UNIX (und Unix) alles auch eine Datei ist, stimmt das natürlich nur bedingt. Unter Linux gab es mal einen USB-Drucker-Treiber, der ohne /dev/usb* ausgekommen ist. Ich kann nur vermuten, dass ähnliches auch unter UNIX möglich ist und war, und dass es Programme gab, die mit Datenströmen ähnlich verfahren sind. Von daher sind für mich eine Datei und ein Datenstrom schon zwei unterschiedliche Sachen. /dev/* wird im Artikel Datei übrigens mit Pseudodatei bezeichnet und nach Gerätedatei verwiesen.

Ja, und? Natürlich ist zwischen "Datei" und "Datenstrom" ein Unterschied, aber dieser Unterschied verschwindet unter UNIX (und ähnlichen), weil das (bzw. - ein) Bauprinzip von UNIX ist, diesen Unterschied verschwinden zu lassen. Das (und nichts anderes) ist eben das Prinzip "alles ist eine Datei". Was Linux genau macht oder nicht - Linux ist eben nur "ähnlich" - ist in dem Zusammenhang unerheblich. Autos haben 4 Räder. Dennoch hat BMW mal was hergestellt, was nur 3 Räder hatte (die "Isetta"). Was genau heißt das jetzt? Na, eben, daß dieses Ding nur "autoähnlich" ist und genau das einen der Unterschiede - zur sonstigen Äquivalenz - ausmacht.

Auch aus diesem Grund verwende ich "UNIX und UNIX-ähnlich": weil "UNIX" (per Standard) festgelegt ist und ich daher mit Sicherheit sagen kann, etwas ist UNIX oder ist es eben nicht. Was "Unix" ist, das definiert ist als "na, alles was so ähnlich ist", gibt es jede Menge Grauzonen und ob eine bestimmte Ähnlichkeit größer oder kleiner oder überhaupt (nicht) vorhanden ist, liegt immer im Auge des Betrachters. Das ist dann wirklich POV, den wir ja angeblich vermeiden sollen. Wieviel Grau genau ist denn noch "weiß-ähnlich" und ist "schwarz" dann auch eine Form von "Weiß-ähnlichkeit"? Das Problem - aber darüber hat Ludwig Wittgenstein schon einen ganzen Tractatus geschrieben - ist, daß man mit undefinierten Begriffen alles und das Gegenteil davon "beweisen" kann. Aber mit definierten Begriffen zu arbeiten, ist den meisten hier zu POV. --bakunin (Diskussion) 13:20, 28. Apr. 2019 (CEST)

Zu UNIX versus Unix. *BSD hat /dev/null. Das steht sogar in der manpage von BSD. Reicht das als Beleg? NetBSD, OpenBSD und FreeBSD haben das auch, aber wenn du hier einzelne Belege haben willst, bringe ich sie dir natürlich gerne! Linux hat /dev/null, auch das scheint mir hinreichend belegt. Minix hat /dev/null.^{manpage von Minix 3} Darwin und Mac OS X haben /dev/null – wenn der Beleg von OS X 10.9 nicht reicht, bringe ich gerne noch weitere.

Auf meinem Android-Smartphone, Android 7.1.2 mit root-Rechten, habe ich auf der Konsole (Termux) ausprobiert, ob /dev/null vorhanden ist, und das ist es. Wurdert aber auch nicht, läuft dort doch Linux: uname -a gibt Linux localhost 3.4.0-perf-geb244d10da4 #1 SMP PREEMPT Tue Feb 5 17:44:07 UTC 2019 armv71 aus.

NeXTStep könnte man ausprobieren. Im Internet war jetzt nix zu finden, aber das macht nix. Ich werde die Intel-Version von NeXTStep 3.3 einfach mal in einer VM installieren. Auf allen Versionen von Mac OS X, die ich je ausprobiert habe, gab es ein /dev/null. Auch auf Mac OS X Server 1.2v3 (das ist eine Version von Rhapsody, dem direkten Nachfolger von OPENSTEP, also auf NeXTStep basierend) ist es vorhanden.

Da es zahlreiche Unix-Betriebssysteme gibt, bei denen /dev/null da ist – auch wenn sie nicht POSIX-zertifiziert sind – macht es für mich schon Sinn, zu schreiben, dass es „auf allen UNIX- und den meisten Unix-Betriebssystemen /dev/null gibt“. Wie gesagt: ich habe noch kein einziges Unix gefunden, bei dem /dev/null nicht vorhanden gewesen wäre. Wie du aber richtig bemerkt hast habe ich nicht jedes Unix, das es gibt oder je gab, ausprobiert. Was meiner Meinung nach aber die Aussage, dass es bei Unix (*BSD etc.) und unixoiden Betriebssystemen (Minux, Linux,...) im Allgemeinen vorhanden ist, nicht unrealistisch oder unwahrscheinlich macht.

Xenix 1.02.1 (SCO und Microsoft 1983 für IBM PC AT, 8086/8088) und Xenix 2.x (schon 386PC im Allgemeinen, auch 286 und schon 386) hat /dev/null. Das ist aber auch nicht verwunderlich, denn es stammt direkt von AT&T UNIX Version 7 ab, und wenn man der BSD-manpage zum Nullgerät Glauben schenkt, wurde es ja mit AT&T UNIX Version 7 eingeführt. Dazu habe ich jetzt zwar keine Quelle gefunden, aber man kann Xenix z.B. auf einem PC-Emulator installieren und findet das Nullgerät dort dann vor.

Wenn man sich jetzt noch dessen Bewusst ist, dass es das Nullgerät /dev/null schon auf den damals üblichen 16-Bit-Computern gab, bei denen Speicherverbrauch und Ressourcen nach heutigen Maßstäben stark begrenzt erscheinen, dann verwundert es wiederum nicht, dass es auch z.B. auf Smartphones nicht deaktiviert wurde.

Ich sags nochmal: ich bezweifle nicht (und habe auch nie bezweifelt), daß /dev/null zur Standard-Ausrüstung der meistten UNIX-ähnlichen Betriebssysteme gehört. Darüber hinaus kann ich deine Liste noch verlängern: SINIX, QNX, Apollo Domain OS, Irix und Interactive ix/386 hatten alle ein /dev/null, was ich aus eigener Erfahrung damit weiß. Ich glaube, ich habe im Keller sogar noch eine O2 herumstehen, falls die noch bootet, könnte ich für IRIX sogar einen Beleg liefern. Ich kann nur nicht belegen, daß alle (im Gegensatz zu "die meisten" oder "viele" oder dgl.) eins haben. Ich will hier aber keine - mehr oder weniger gesicherten - Vermutungen kolportieren, sondern - WISSEN. Darum sollte es IMHO eine Formulierung sein, die sagt, daß:

1. Alle UNIX-Systeme eins haben müssen (weil belegbar)
2. viele UNIX-ähnlichen Systeme (vermutlich die Mehrzahl, aber das ist Vermutung und als solche kenntlich zu machen) eins haben
3. (optional, aber auch das ist Vermutung, es UNIX-ähnliche Systeme geben könnte, die keins haben)

--bakunin (Diskussion) 13:20, 28. Apr. 2019 (CEST)

Die Frage ist nun, wie formulieren wir das ganze.

Ich würde es etwas neutraler formulieren, wie folgt:

• Statt
  • „/dev/null ist ein Device, das in vielen Betriebssystemen als Ziel zu entsorgender Datenströme fungiert.“
  • „/dev/null ist die Implementierung des Nullgeräts auf vielen Unix-Betriebssystemen.“
• Begründung: „Ein Device, das als Ziel zu entsorgender Datenströme fungiert“ ist bereits im Artikel Nullgerät definiert und dort nachzulesen.

Damit kann ich leben, lediglich - Siehe die Begründung zu Graden der Ähnlichkeit oben - würde ich "UNIX- und UNIX-ähnliche" vorziehen, denn - auch in dem immer wieder zitierten Artikel und der Diskussion "Unix" - gibt es eben nirgendwo eine allgemein verbindliche Definition, was genau "Unix" ist und was ein System genau sein muß, damit es als "Unix" bezeichnet wird. Was hingegen "UNIX" ist, ist im Einzelnen haarscharf abgrenzbar. --bakunin (Diskussion) 13:20, 28. Apr. 2019 (CEST)

Den Rest der Einleitung würde ich so lassen. Denn, dass es in POSIX vorgeschrieben ist, ist zu 100% richtig, und dass es in UNIX seinen Anfang nahm auch.

Gibt es Einwände dagegen?

Ich wäre allerdings dankbar, wenn du dein Wissen auch in den Artikeln

1. Nullgerät
2. Datenstrom
3. Datei
4. Gerätedatei

einbringen würdest.

‣Andreas•⚖ 23:31, 26. Apr. 2019 (CEST)

Siehe oben, warum ich das nicht tun werde. Allerdings muß ich dir das Kompliment machen, daß du - für mich das erstemal seit langem - eine sachliche Diskussion, bei der meiner Einschätzung nach auch was herausgekommen ist, geführt hast. Ich hatte anfangs die Befürchtung, daß es - siehe die verlinkte Diskussion zu cat (Unix) - genauso wie immer enden wird, weshalb ich am Anfang sarkastischer war, als ich es, im Nachhinein betrachtet, gerne gewesen wäre. Ich bitte das zu entschuldigen. --bakunin (Diskussion) 13:20, 28. Apr. 2019 (CEST)

Unixoid

Der Begriff unixoid wird im zugehörigen Artikel erklärt. Ich schlage also vor, vor dem Revert der Einfügung dieses Begriffes erst den Artikel zu lesen. --Rôtkæppchen₆₈ 01:54, 11. Jul. 2018 (CEST)

POSIX

Mag sein, dass /dev/null auch in POSIX definiert ist. Jedoch ist auch Windows NT ein POSIX-konformes System, jedoch ohne /dev/null.

‣Andreas•⚖ 10:16, 11. Jul. 2018 (CEST)

Nein, wenns kein /dev/null hat, dann ist es eben NICHT POSIX-konform. Aber da wir diese Sau schon zum x-ten Mal durchs Dorf treiben, hier das Zitat aus dem - angeblich rein theoretischen und öffentlich nicht verfügbaren - Standard: In Kapitel 10, "Directory Structure and Devices" heißt es unter Punkt 10.1, "Directory Structure and Files"

The following directories shall exist on conforming systems and conforming applications shall make use of them only as described.

[...]

/dev

Contains /dev/console, /dev/null, and /dev/tty, described below.

/dev/null

An empty data source and infinite data sink. Data written to /dev/null shall be discarded. Reads from /dev/null shall always return end-of-file (EOF).

Die paar angeführten Directories und Files nehmen insofern eine Sonderstellung ein, als POSIX (etwa zum Unterschied zum bei Linux oft verwendeten FHS) im Allgemeinen KEINE Angabe zu Pfaden macht. Über die Lokation der Standard-Shell sh wird beispielsweise gesagt:

Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.

For example, to determine the location of the standard sh utility:

command -v sh

Bei diesen wenigen Files und Directories wird von diesem Schema aber abgewichen. --bakunin (Diskussion) 21:31, 23. Apr. 2019 (CEST)

Nachtrag: @Bakunin: Ach ja, betrifft diese Änderung. ‣Andreas•⚖ 10:23, 11. Jul. 2018 (CEST)

@Y2kbug:, Windows NT hat NULL bzw. \Device\Null. POSIX-kompatibel ist das nur mit installiertem Subsystem (POSIX-Subsystem, en: Microsoft POSIX subsystem; Microsoft Windows Services for UNIX, en: Windows Services for UNIX, Windows Subsystem for Linux), dann hat es auch /dev/null. LG, ℳ웃79 17:38, 28. Apr. 2019 (CEST)

Zum Verhältis von POSIX, SUS und der Marke UNIX

Anläßlich der oben geführten Diskussion habe ich mal genauer nachgeforscht und dabei kam folgendes zu Tage:

• Der POSIX-Standard (um ganz genau zu sein: "The Open Group Technical Standard Base specification, Issue 7 (2018)" ist der derzeit aktuelle Standard für UNIX-Systeme (also Systeme, die nicht nur "Unix" oder "unixähnlich" sind, sondern richtige UNIX-Systeme). Dieser Standard kann hier:

http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm

eingesehen werden. Dieser Standard ist zugleich auch der Standard IEEE1003.1n (1003.1 besteht aus einigen Teilstandards) der IEEE beziehungsweise der Standard IEC/ISO 9945 der ISO bze. der IEC. "POSIX", "IEC9945", "ISO9945", "IEEE1003.1" sind Synonyme. Der Grund, warum die ISO/IEC-Standards nicht im angeführten Link erwähnt werden, ist, daß die Abstimmung der ISO/IEC erst nach der Verabschiedung des Open-Group-Standards durchgeführt wurde, als dieser schon veröffentlicht war. Trotzdem ist "ISO/IEC 9945-1:2018" dasselbe wie The Open Group Technical Standard Base specification, Issue 7 (2018)". oder "IEEE 1003.1-2017".

• Um nach POSIX zertifiziert zu werden, reicht die Einhaltung der verbindlich geforderten Teile, optionale Bereiche müssen nicht erfüllt werden. Der Prozeß der POSIX-Zertifizierung ist kostenpflichtig.

• Die "Single UNIX Specification" ist ebenfalls gleichbedeutend mit dem POSIX-Standard, genauer: mit dem "Open Group Technical Standard Base", was nur ein anderer Name dafür ist. In dem oben angeführten Link steht in Section 2 der "Base Definitions" (unter dem Titel "Conformance"), daß der POSIX-Standard verbindliche ("mandatory") und optionale ("optional") Teile enthält.

• Was genau ist "UNIX"?

Um sich "UNIX" nennen zu dürfen, muß ein System:

• • die Bedingungen für die POSIX-Zertifizierung erfüllen;
  • den Zertifizierungsprozeß (kostenpflichtig) durchlaufen;
  • außerdem die (optionalen) Teile der "X/Open Systems Interface Option" alle erfüllen.
  • Darüber hinaus muß eine Konformitätserklärung seitens des Herstellers unterzeichnet werden.

ISO und IEC hat kein eigenes POSIX branding oder Zertfizierungsprozeß für ihren 9945-1 Standard.

Ich hoffe, mit dieser Information die Diskussion, warum man den POSIX-Standard und nicht die SUS (oder vice versa) als Quelle anführt, beendet zu haben. --bakunin (Diskussion) 20:52, 26. Apr. 2019 (CEST)

Danke für deine Zusammenfassung, sie ist sehr aufschlussreich. Man lernt nie aus. ‣Andreas•⚖ 23:39, 26. Apr. 2019 (CEST)

Das sind – richtige – Aussagen zu POSIX an sich. Aber. Die aktuelle SUS ist „technically identical“ zu

1. POSIX = IEEE Std 1003.1-2017 and ISO/IEC 9945:2009 including ISO/IEC 9945:2009/Cor 1:2013(E) and ISO/IEC 9945:2009/Cor 2:2017(E)
2. X/Open Curses.

zusammen („with the addition of“). Steht halt so da. LG, ℳ웃79 14:33, 28. Apr. 2019 (CEST)

UNIX, UNIX-Derivate, Unix, Unix-ähnliche Betriebssysteme und POSIX

Ich habe jetzt mal mit Google Books recherchiert, um den Unterschied bzw. die eindeutige Definition von UNIX, Unix, Unix-ähnlich usw. zu verstehen und habe eigentlich nur die Geschichte von UNIX gefunden. Im Grundtenor werden alle Unices in den selben Topf geworfen.

Dies nur als Beispiel dafür, was eigentlich durchwegs zu lesen ist:

• UNIX-Systemadministration: Linux, Solaris, AIX, FreeBSD, Tru64-UNIX (Seiten 1-3), Konrad Heuer, Reinhard Sippel, Springer-Verlag, 2013

Interessant auch, dass das Wort „Unices“ für die Mehrzahl von Unix bereits 1985 in diesem Buch auftaucht:

• Online, Anwenderverband Deutscher Informationsverarbeiter, Verlagsgesellschaft R. Müller, 1985

Nach der Veröffentlichung von UNIX im Quelltext entwickelten sich offenbar zwei zueinander konkurrierende Hauptlinien. Die eine, von AT&T betriebene Linie mündete schließlich 1989 in UNIX System V Release 4 (auch SVR4 abgekürzt); die andere war landläufig auch BSD-UNIX bezeichnet worden, wurde bereits in den 1970er Jahren parallel zu System V entwickelt, bis sie 1995 schließlich in 4.4BSD-Lite2 mündete. Seither wird *BSD frei von mehreren Entwicklergemeinden weiterentwickelt. Beide, also System V und BSD, basieren auf UNIX Version 7 ("UNIX Seventh Edition"). Die Verbreitung von UNIX begann offenbar mit UNIX Version 6 von 1975, aber so richtig durchstarten konnte UNIX erst mit der auf Portierbarkeit getrimmten Version 7, die als Basis von UNIX System-V diente. Bekannt ist auch der Vorgänger mit dem Namen System III. Doch System V von AT&T und BSD-UNIX von Berkeley CSRG verfolgten andere Ziele und wurden teils inkompatibel weiterentwickelt; BSD-UNIX war aber so erfolgreich, dass System V (SVR4) viele der BSD-Entwicklungen übernommen hat bzw. schließlich übernehmen musste (ein berühmtestes Beispiel ist sicher virtueller Speicher, der erstmals in 3BSD von 1979 implementiert wurde). Der UNIX-Standard, auch POSIX genannt, besteht also ebenso aus AT&T-Entwicklungen ("Original-UNIX", wenn man so will) wie aus BSD-Entwicklungen der Computer Science Research Group (CSRG) aus Berkeley.

Siehe dazu auch:

• Einführung in UNIX: Ein Lehr- und Arbeitsbuch für Studium und Praxis, Werner Brecht, 2. Ausgabe, Springer-Verlag, 2013 (ISBN 9783663120735)

Zusammenfassend:

• UNIX Version 1 (1971) und UNIX Version 2 (1972), noch in Assembler geschrieben (und damit schwer portierbar)
• UNIX Version 6 (1975), bereits in C geschrieben
• UNIX Version 7 (ab 1977) – sehr erfolgreich, da nun besser portierbar; Basis für Kommerzielle UNIX-Derivate
  • UNIX System V, unter der Bezeichnung "UNIX System V Release n" (z.B. SVR4)
  • BSD-UNIX, unter der Bezeichnung "nBSD" (z.B. 3BSD oder 4.2BSD)

Auf diesen zwei Haupt-Stämmen basieren alle kommeriellen UNIX-Derivate, darunter SINIX (SNI), UNTRIX (DEC), HP-UX (HP), AIX (IBM).

Der Grund, warum die Derivate nicht auch UNIX heißen, ist, dass UNIX ein eingetragenes Warenzeichen ist.

Zu all dem passt auch folgender Satz, den ich hier aus dem erstgenannten Buch „UNIX-Systemadministratoren“ zitieren möchte: „Erwähnung finden soll auch der POSIX-Standard, mit dem der Versuch unternommen wird, eine Programmierschnittstelle für ein offenes Betriebssystem auf UNIX-Basis zu beschreiben.“

Da die kommerziellen UNIX-Derviate teils inkompatible Eigenentwicklungen aufzuweisen begannen, musste notgedrungen ein Standard geschaffen werden, um ein Auseinanderdriften von UNIX und dessen Derevaten zu verhindern und damit UNIX-Programme auf allen UNIX-Betriebssystemen auch weiterhin nutzbar blieben. Allerdings ist POSIX auf die Portierbarkeit des Quelltextes getrimmt, nicht auf die von kompiliertem Code (Binaries). Es kann also ein POSIX-konformes Programm sowohl auf AIX als auch auf 4.3BSD als auch auf SVR4 als auch auf HP-UX kompiliert werden und sollte funktionieren. Andere Standardisierungsversuche waren z.B. SVID: „System V Interface Definition“. Zusammenschlüsse wie X/OPEN, OSF (Open Software Foundation) und UI (UNIX International) folgten. Mit dem Erfolg von BSD-UNIX und der Annäherung von SVR4 ist POSIX Ende der 1980er Jahre für alle Unices gleichermaßen anwendbar.

Das o.g. Buch listet

• folgende kommerzielle UNIX-Betriebssysteme: „u.a. AIX, BSD/OS Compaq/HP Tru64-UNIX, HP-UX, IRIX, Solaris/SunOS, UNICOS und Mac OS X“.
• folgende BSD-UNIX-Derviate: „FreeBSD, NetBSD, OpenBSD und Darwin“
• folgende UNIX-artige: Linux

Da Neuentwicklungen wie MINIX und Linux sich nach den bereits existierenden UNIX-Derivaten richteten, suchen sie ebenso die Nähe zum offenen POSIX-Standard, um die Kompatiblität zu Unix-Programmen auf Quelltext-Ebene nicht zu verspielen.

Das ist aber alles nur eine Randerscheinung und OT (off-topic). Wenn es um das Nullgerät /dev/null geht, dann kann man davon ausgehen, dass sogut wie alle gelisteten Unix-Betriebssysteme eines haben. Und wenn man schon nicht schreiben will, dass es so ist – weil man ja nicht alle Unices kennen und danach abklopfen kann – so kann man dann doch davon ausgehen, dass es im Allgemeinen so ist.

Die von mir daher bevorzugte Formulierung der Einleitung sieht daher wie folgt aus:

/dev/null ist eine virtuelle Gerätedatei, die auf Unix-Betriebssystemen das Nullgerät implementiert. Im POSIX-Standard ist seine Existenz für UNIX-Systeme vorgeschrieben^ref und sein Verhalten standardisiert. Seinen Ursprung hat /dev/null im Betriebssystem UNIX Version 7 von 1977.^ref

Dorthin adressierte Datenströme werden verworfen, beim Lesezugriff darauf wird ein einzelnes End-of-File-Zeichen (EOF) ausgegeben.

Die Einleitung ist deshalb nicht falsch, weil, wenn ein Unix-Betriebssystem das Nullgerät implementiert, dann als /dev/null. Die Formulierung schließt also nicht aus, dass das Gerät eventuell fehlt. Und Unix-Betriebssysteme lehnen sich quasi immer an POSIX an, weil sie nicht mit Gewalt inkompatibel sein wollen. So heißt es bei Linux in der README-Datei: Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specification compliance.^README

Was die Anglizismen und die deutschen Übersetzungen betrifft – ja, ich verwende auch oft lieber die englischen Begriffe. Aber darum geht es nicht. Es geht darum, den Lesern der Wikipedia zu erklären, was es mit einem Begriff aufsich hat. Und wenn Otto-Normal-User — ;-) "Anwender"/"Benutzer" ;-) — etwas über das Nullgerät /dev/null erfahren will, dann sollten wir ihm die verfügbaren deutschen Begriffe vermitteln, wie man sie auch in der deutschen Fachliteratur vorfindet. Für diejenigen, die etwas tiefer in die Materie eintauchen wollen, sollten wir auf jeden Fall auch die englischen Fachausdrücke dazuschreiben, ja, definitiv! (In Klammern, hinter dem deutschen Begriff; die Vorlage:enS hilft hier sehr…)

Nun ist es so, dass ich in der Fachliteratur auch die Gerätedateien für /dev/* gefunden habe. Dass /dev/null eine virtuelle Gerätedatei ist liegt in der Natur des Nullgeräts selbst (es ist mit keinem Device verbunden, daher virtuell). Aber darüber können wir gerne noch streiten.

Dass ich persönlich am liebsten von special files schreiben würde, tut nicht zur Sache. Dass meine persönliche Vorliebe die Trennung zwischen Unix und Unix-artig ist, und nicht unixoides System, tut auch nichts zur Sache. Tatsache ist, dass wir diese Artikel bereits so in der Wikipedia vorfinden. r das gleiche meinen wie die Artikel, die es schon gibt und die man einfach verlinken kann. Das Dateisystem zumWir sollten es den Lesern nicht unnötig schwer machen und andere Betriffe einführen, die wir zwar persönlich für treffender halten, die abe Beispiel.

@Bakunin: Ich verstehe dich sehr gut. Und ich bin dir sehr dankbar, dass du dich hier einbringst. Aber es wird über kurz oder lang nicht funktionieren, dass du bei UNIX-Artikeln andere Begriffe nutzt als die, die es in der Wikipedia bereits gibt und die in vielen anderen Artikeln bereits genutzt werden.

Im Endresultat wirst du dich leider nicht aus dem Kampf (Diskussionen) herausnehmen können, wenn du gute Argumente hast. Ich kann dir allerdings versichern, dass ich dir gerne zur Seite stehe, wenn du gute Argumente (und Belege) hast. Nun habe ich natürlich auch nicht immer Zeit, aber vielleicht lässt sich da ja was machen. Wie gesagt: das bessere Argument sollte stechen, denn wer etwas ausreichend gut belegen und argumentieren kann, der gewinnt langfristig – wenn er nicht aufgibt.

Stell es dir so vor: Du gewinnst sicher nicht immer, aber das Ziel ist nicht dein Sieg, sondern bessere Artikel in der Wikipedia. Ich sehe das genauso, denn, wie du ja schon bemerkt hast, bin ich auch das eine oder andere Mal eines Besseren belehrt worden! (Danke!) Aber das Ziel – bessere Artikel – ist ein Gewinn für uns alle, und daher oft den Kampf wert. Oft hilft auch ein erneuter Anlauf nach einer längeren Pause – auf jeden Fall dann immer, wenn du Belege und Argumente auf deiner Seite hast.

‣Andreas•⚖ 21:50, 28. Apr. 2019 (CEST)

Sorry, hat ein wenig gedauert mit der Antwort.

Erstmal die (hier) wichtigste Sache. Du sagst:

„Die von mir daher bevorzugte Formulierung der Einleitung sieht daher wie folgt aus:

/dev/null ist eine virtuelle Gerätedatei, die auf Unix-Betriebssystemen das Nullgerät implementiert. Im POSIX-Standard ist seine Existenz für UNIX-Systeme vorgeschrieben^ref und sein Verhalten standardisiert. Seinen Ursprung hat /dev/null im Betriebssystem UNIX Version 7 von 1977.^ref

Dorthin adressierte Datenströme werden verworfen, beim Lesezugriff darauf wird ein einzelnes End-of-File-Zeichen (EOF) ausgegeben.“

– Y2kbug: Einlassung vom 28. Apr. 2019, 21:50

Soweit kann ich damit leben. Ich bin immer noch gegen die "virtuelle Gerätedatei" - aus den oben genannten Gründen - und ich bin auch nicht der Meinung, daß "wenn schon einmal falsch, dann bitte immer falsch" ein enzyklopädisches Prinzip darstellt, aber ich will auch den Artikel irgendwann zu einem Abschluß bringen. Er wird sowieso früh genug von den eigentlichen Fachleuten - siehe etwa exec (Unix) - so richtiggestellt werden, daß wir ihn vermutlich beide nicht mehr erkennen.

Das Thema "POSIX und Unix und UNIX" wäre einer weiteren Erörterung würdig, aber hier off topic. GNU-Tools etwa verstoßen oft genug bewußt gegen POSIX-Richtlinien, weil sie das, was sie selber tun, für besser als POSIX halten (als Beispiel: GNU-BREs vs. POSIX-BREs, "sed -i", "--" als Einleitung von Langform-Optionen, etc.). Ob das wirklich besser ist oder nicht, will ich gar nicht diskutieren, aber "anders" bzw. "nicht mit dem Standard übereinstimmend" ist es allemal und es macht mein Leben als Script-Programmierer erheblich schwerer, zwei verschiedene Standards zu unterstützen, als nur einen, selbst, wenn es der "schlechtere" wäre.

Soweit es die Anglizismen betrifft, finde ich deinen Ansatz allerdings falsch. Du sagst:

„Es geht darum, den Lesern der Wikipedia zu erklären, was es mit einem Begriff aufsich hat. Und wenn Otto-Normal-User — ;-) "Anwender"/"Benutzer" ;-) — etwas über das Nullgerät /dev/null erfahren will, dann sollten wir ihm die verfügbaren deutschen Begriffe vermitteln, wie man sie auch in der deutschen Fachliteratur vorfindet.“

– Y2kbug: Einlassung vom 28. Apr. 2019, 21:50

Die - deutsche - Fachliteratur ist sich, was die Verwendung von Termini Technici angeht, erstens ebenfalls durchaus uneins. Für jedes Buch, das zB. "Array" als "Vektor" (auch so ein schönes deutsches Wort) übersetzt (siehe die Deutsche Übersetzung von "The C Programming Language" von Kernighan/Ritchie), findet man ein anderes, das das korrekte "Array" stehen läßt (zB die deutsche Übersetzung des "Dragon Books": "Compilerbau", Aho/Sethi/Ullmann). Zum Zweiten bin ich nicht der Meinung mancher Eltern, daß man den Kindern erst Lügen über den Osterhasen auftischen muß, bevor man ihnen die Wahrheit erzählt - nämlich, daß es ihn nicht gibt. (Obwohl es den noch eher gibt als vernünftige deutsche Fachbegriffe.) Mal ganz abgesehen davon, daß unter Nullgerät steht, das Ding sei ein Ausgabegerät, was /dev/null ja eben nicht ist, denn daß es in der Lage ist, EOF auszugeben, ist sicher nicht sein Hauptzweck, das selbe findet sich übrigens unter Ausgabegerät. Aber davon ganz abgesehen liefert Google für den Suchbegriff "Nullgerät" "ungefähr 23.100 Treffer" und für "null device" "Ungefähr 185.000.000" - darunter als erstes (!) den vorliegenden Artikel und für "nulldevice" immer noch 129.000 Treffer mit /dev/null ebenfalls in erster Position. Das Argument, den Artikel leichter auffindbar zu machen, indem man die Terminologie einer Randgruppe aufgreift, zieht also nicht.

Ich bin gar nicht dagegen, den "Lesern [...] zu erklären, was es mit einem Begriff auf[ ]sich hat", aber ich würde ihnen lieber den echten Begriff erklären, als irgendeine Übersetzung, von der ich erstmal erklären muß, daß nicht das gemeint ist, was gesagt wird, bevor ich darangehen kann, zu erklären was es ist. Bevor ich den Lesern erklären kann, was ein "Gerät" in dem Zusammenhang ist, muß ich ihnen erstmal sagen, daß es eben kein "Gerät" ist und daß das "virtuelle Gerät" nicht mal ein "Gerät" ist, das eben kein Gerät ist, sondern ... - ob das wirklich zur Klarheit beiträgt, mag dahingestellt sein. Es heißt immer, hier soll keine Theoriefindung betrieben werden, aber genau das wird hier gemacht.

Ich sags nochmal: die Mediziner kümmern sich auch einen Dreck darum, was "Luxation" auf deutsch heißt. Die sagen einfach "Luxation", obwohl der Begriff außerhalb des medizinischen Bereichs im Deutschen nicht verwendet wird. Und, möchte ich hinzufügen, sie haben recht damit! Sie bedienen sich eben eines in ihrem Fachgebiet etablierten Vokabulars! Und dann klassifizieren sie noch innerhalb der Schulterluxation (nicht "Schulterumrichtung") diverse Läsionen, Rupturen und Frakturen - warum, glaubst du, nicht "Verletzungen", "Zerreißungen" und "Brüche", hm? Eben, weil diese Begriffe genau definierte Bedeutungen haben und für einen Mediziner eine "Fraktur" nicht dasselbe ist, wie für einen Laien ein "Bruch". Und lieber erkläre ich einem Laien, was ein Mediziner unter "Fraktur" versteht, als einem Laien erst zu erklären, daß es ein "Bruch" ist, dann, daß es eben kein "richtiger Bruch", sondern mehr so ein "virtueller Bruch", schließlich, daß es eigentlich überhaupt kein "Bruch" ist und ganz am Ende, daß wir die ganze Zeit von einer "Fraktur" gesprochen haben. Das ist nicht laienfreundlich, das ist verwirrend und umständlich.

Wir haben es hier mit mit "OMA" (ohne mindeste Ahnung) zu tun, schreiben aber, als wäre das gleichbedeutend mit "OMI" (ohne mindeste Intelligenz). Das ist respektlos, von oben herab - und außerdem grundfalsch, weil nicht jeder, der nichts von einem beliebigen Fachgebiet versteht, automatisch gleich ein Depp ist.

Als letztes, eher als persönliche Anmerkung: du redest oben vom "Kampf", von dem ich mich nicht ausnehmen könnte und vom "Sieg", den ich nicht immer davontragen würde. Ich sehe das hier nicht ganz so kriegerisch. Mir geht es nicht darum, zu "siegen" oder auch nur "rechtzubehalten", sondern ich will die Artikel hier besser gemacht sehen. Ob von mir oder jemand anders, ist mir gleichgültig. Andererseits ist mir bewußt, daß sich hier nicht die besseren Argumente durchsetzen, sondern die Masse. Dem habe ich nichts entgegenzusetzen und lasse deshalb selbst den Versuch. Wenn du was von mir lesen willst: https://www.unix.com, dort liegen über 6000 Artikel von mir. --bakunin (Diskussion) 12:58, 3. Mai 2019 (CEST)

Kein Problem, dass es länger gedauert hat.

Du erstaunst mich immer wieder... Das Argument, dass die medizinischen Fachausdrücke halten und die im Computerumfeld nicht, ist ein gutes.

That said… Was ich nicht mag, ist die Nutzung von Begriffen, für die es ein deutsches Wort gibt, das nochdazu auch Verwendung findet. Z.B. das ganz triviale Softwareupdate. Durchübersetzte Betriebssysteme verwenden hier das Wort Softwareaktualisierung. Warum wird Software nicht übersetzt? Weil es kein passendes deutsches Wort dafür gibt. Das Update in diesem Fall ist aber die Aktualisierung. (Wir reden hier nicht von einem Datenbank-Update and auch nicht von einerm Update-Routine…) Nur Windows von Microsoft war bis Windows XP so verschrogen übersetzt, dass sogar das Verb ins deutsche Passiv gepresst wurde und dann wurde Windows „upgedated“ statt aktualisiert.

Ob nun Deutsch oder English, dass wäre eine längere Diskussion wert und ich bin – ja, du hast mich überzeugt – nun klar für die englischen Begriffe, wenn diese keine eindeutige deutsche Übersetzung aufweisen. (Array, Update als Routine oder Funktion in einem Programm etc.)

Was OMA betrifft, so hast du bei den Geräten allerdings deshalb etwas außen vor gelassen, weil Microsoft seit langem dafür sorgt, das Millionen von Anwendern mit dem Begriff der „Gerätetreiber“ vertraut sind. Und wo findet man diese? Na, im Gerätemanager.

Es wäre eine eigene Diskussion wert (etwa auf der Diskussionseite der Redaktion Information) und vielleicht sollte man endlich einmal klären, wie wir Begriffe im Bereich Information und IT nutzen – englisch oder deutsch, und wenn, wann welchen der beiden hauptsächlich. (So wie es auch im medizinischen Bereich geregelt ist.) Beim Array macht es wohl mehr Sinn, es englisch zu belassen. Auch bei Software wird das ja so gemacht, und es heißt Computer und nicht Rechenmaschine. Soweit sind wir uns wohl einig.

Wie die deutsche Fachliteratur da genau hineinpasst wäre eben noch zu bestimmen. Und wie wir das im Normalfall in eine Einleitung zu einem Artikel darstellen ebenso. (Bei der Luxation ist der erste Absatz ja ein traumhaftes Beispiel dafür, wie man es machen kann!)

Viele Betriebssysteme wurden zuanfangs gar nicht aus dem Englischen übersetzt, und als es dann doch getan wurde, nur teilweise. Updates sind so ein Beispiel.

Es gibt allerdings gut ins Deutsche übersetzte Betriebssysteme (und Software im allgemeinen), und an die kann man sich dann schon halten. Dass es z.B. Festplatte heißt, für englisch Hard Disk Drive, ist hoffentlich mittlerweile etabliert.

Wie dem auch sei, es ist deshalb ein Kampf, weil man Energie hineinstecken muss und sich etwas erstreiten muss. Ich bin sehr froh darüber, dass du den Begriff Sieg so kritisch siehst und dasselbe Ziel hast wie ich (und wie hoffentlich jeder Autor), nämlich gute Artikel.

‣Andreas•⚖ 15:39, 3. Mai 2019 (CEST)

Nachtrag: siehe Wikipedia Diskussion:Redaktion Informatik#Fachbegriffe auf Englisch, oder die deutsche Übersetzung?... mein Versuch, hier weiterzukommen. ‣Andreas•⚖ 21:40, 3. Mai 2019 (CEST)

Bearbeitungsbaustein

Ich werde diesen Artikel nicht mehr anfassen, mir reichts. Folgende Unrichtigkeiten sind nach dieser "Überarbeitung" mittlerweile drin:

"/dev/null ist die Implementierung eines Nullgeräts"

Was soll "eines" heißen? Gibts denn mehrere?

Erl. ‣Andreas•⚖ 12:20, 19. Mai 2019 (CEST)

"in Unix-Betriebssystemen als Gerätedatei."

Erstens ist /dev/null nicht in jedem "Unix-System" vorhanden. Beispiel: eLinux mit cramfs (wie ich weiter oben schon vermutet habe, nur was ich bisher zu faul zum Suchen). Ist eLinux jetzt kein "Unix-System" oder sollte der Unsinn üer "Unix-Systeme" nicht besser wieder raus bzw. zumindest deutlich eingeschränkt werden?

Es steht nicht da, dass es in jedem Unix-System vorhanden sein muss, oder dies wäre. Es steht nur da, dass es die Implementierung des Nullgeräts auf Unix-Systemen ist. Wenn also ein Unix ein Nullgerät implementiert, dann macht es dies über /dev/null.

‣Andreas•⚖ 12:23, 19. Mai 2019 (CEST)

Ein Versuch: https://de.wikipedia.org/w/index.php?title=/dev/null&oldid=189008634&diff=cur&diffmode=visual --Max Schröder (Diskussion | Kontakt) 22:54, 9. Aug. 2019 (CEST)

Danke, aber... nein. Wenn du dir den verlinkten Artikel Unix ansiehst, dann wirst du erkennen, dass dieser nicht nur AT&T-UNIX beschreibt. BSD und Linux ist dort ebenso vertreten wie die meisten direkt von UNIX abstammenden Betriebssysteme. Unix ist in diesem Zusammenhang also die Systemarchitektur, die naturgemäß auch von Unix-artigen Betriebssystemen umgesetzt wird. Damit ist /dev/null die Implementierung des Nullgeräts in Unix-Betriebssystemen als Gerätedatei.

Trotdem: vielen Dank für den Versuch! ‣Andreas•⚖ 23:45, 9. Aug. 2019 (CEST)

"BSD und Linux ist dort ebenso vertreten wie die meisten direkt von UNIX abstammenden Betriebssysteme."

Ich zitiere aus dem Artikel Unix:

"Andere Systeme wie Linux oder QNX basieren hingegen nicht auf dem ursprünglichen Unix-Quelltext, sondern wurden separat entwickelt. Sie werden als „unixoide Systeme“ bezeichnet, weil sie einen Teil der für Unix standardisiert definierten Betriebssystemfunktionen (POSIX) ebenfalls implementieren."

Diese Trennung ist in der englischsprachigen Version (auch in mehreren anderen Sprachversionen) sowie im Artikel Nullgerät ebenfalls erfolgt. Im Artikel Linux ist Linux eindeutig als unixähnlich spezifiziert. --Max Schröder (Diskussion | Kontakt) 00:54, 10. Aug. 2019 (CEST)

Das stimmt alles. Aber das Nullgerät /dev/null ist trotzdem die Implementierung von Unix. Diese wird eben auch in Unix-artigen Betriebssystemen verwendet. Und wenn es in Systemen, die mit Unix überhaupt nichts zu tun haben, auch als /dev/null implementiert wäre, so wäre es dennoch immer noch die Implementierung des Nullgeräts von Unix – dann eben auf einem Nicht-Unix-System.

Ist das irgendwie verständlich? Es geht hier um eine Architektur, nicht um ein Betriebssystem. Unix-artige Betriebssysteme wie Linux, Minix usw. nutzen großteils die Unix-Betriebssystemarchitektur. Dass sie nicht Unix heißen dürfen hat nichts mit deren Aufbau zu tun – zu dem Unix-Konzepte wie /dev/null zählen.

‣Andreas•⚖ 01:03, 10. Aug. 2019 (CEST)

Ach ja, im Artikel Nullgerät sind einzelne Betriebssysteme gelistet. Da muss man dann die Unterscheidung machen. (Z.B. CP/M und DOS, und dann eben auch Unix und Unix-artig...) ‣Andreas•⚖ 01:05, 10. Aug. 2019 (CEST)

Update: Eigentlich steht das alles im zweiten Absatz: (ich zitiere)

Bei SUS-zertifizierten und POSIX-konformen UNIX-Betriebssystemen ist /dev/null zwingend erforderlich. Viele weitere Unix-artige Betriebssysteme, darunter BSD-basiertes Unix wie die BSD-Nachfolgeprojekte NetBSD, FreeBSD und OpenBSD, sowie unzählige Linux-Distributionen, halten sich beim Nullgerät an den mit POSIX vorgegebenen Standard. Auf anderen Betriebssystemen ist /dev/null auf POSIX-konformen Unix-Shells ebenfalls implementiert, etwa mit Cygwin unter Windows.

Dass es rein um die konzeptionelle Implementierung geht, zeigt doch gerade Cygwin unter Windows – hier wird das Unix-Nullgerät unter Windows NT implementiert. Und bei Unix-artigen Betriebssystemen wird auch das Unix-Nullgerät implementiert. ‣Andreas•⚖ 01:13, 10. Aug. 2019 (CEST)

Stimmt, hast recht. --Max Schröder (Diskussion | Kontakt) 01:19, 10. Aug. 2019 (CEST)

Zweitens sollte man, wenn man schon so vollmundig von "Gerätedatei" spricht, erklären, daß es kein Gerät gibt, auch kein "virtuelles". Andererseits: wenn man Laien dumm sterben läßt, ist das viel OMA-freundlicher.

Ja, da gebe ich dir zu 100% recht, das gehört überarbeitet. Ich würde im Artikel Gerätedatei anfangen.

‣Andreas•⚖ 12:23, 19. Mai 2019 (CEST)

"zertifizierte UNIX-Systeme"

Das "zertifizierte" verlinkt im Artikel auf die Single UNIX Specification, die aber /dev/null mit keinem Wort erwähnt. Tatsächlich wird /dev/null - wie von mir geschrieben, aber eiligst auf diesen Schwachsinn verbessert - vom POSIX-Standard vorgeschrieben. Das Device müssen also alle POSIX-KONFORMEN Systeme haben (zu denen auch alle UNIX-Systeme zählen, aber die sind nicht die einzigen, wie wir hinlänglich diskutiert haben. Wenn man hin und wieder mal einen Standard auch lesen würde, wäre das vielleicht klarer.

Ja. Und was macht eine SUS-Zertifizierung aus? Prüft SUS nicht die Konformität mit POSIX? Ist es damit nicht wieder richtig? ‣Andreas•⚖ 12:25, 19. Mai 2019 (CEST)

Nein, die SUS hat eine besondere Art von POSIX-Konformität zur Voraussetzung. Da aber auf eben diese POSIX-Konformität abgestellt wird und eben POSIX ausdrücklich erwähnt und darauf verwiesen wird, kann man sich das nun wirklich sparen. Außerdem: jeder, der promoviert, muß vorher ein Studium absolviert haben und jeder, der studiert, muß mal Abitur gemacht haben. Dennoch verlinkt man nicht "Promotion" auf "Abitur" - auch, wenn das über drei Ecken eine der Voraussetzungen ist, oder? --bakunin (Diskussion) 15:47, 22. Mai 2019 (CEST)

Ist hier nicht die Laufrichtung umgekehrt? SUS-zertifiziert heißt ja auch POSIX-konform... Und POSIX-konform ist nur ein zertifiziertes Unix eindeutig, denn sonst wäre ja Linux und *BSD ohne SUS-Zertifikat auch POSIX-konform – aber eben nicht gesichert, da nicht getestet, da nicht zertifiziert.

Ich habe es trotzdem geändert und den Einleitungssatz auch gleich deutlich vereinfacht, schlanker gemacht.

Erledigt? ‣Andreas•⚖ 18:28, 22. Mai 2019 (CEST)

Nein, nicht erledigt. Erstens heißt zwar "SUS-Zertifikat" zwar auch "POSIX-konform", wie du sagst, aber umgekehrt "POSIX-konform" (bzw. "POSIX-zertifiziert", was nicht das Gleiche ist) heißt noch nicht "SUS-zertifiziert". Zweitens ist der Satz jetzt sachlich unrichtig, weil sich "Unix-Systeme", wie wir sattsam diskutiert haben, NICHT an den POSIX-Standard halten müssen und deshalb /dev/null implementieren können, wie immer sie wollen - POSIX-konform, beinahe POSIX-konform oder sonstwie. DerSatz impliziert aber, daß sich alle, die nicht zertifiziert sind, trotzdem an den Standard halten, was dir zu belegen schwerfallen wird. Ich schlage mittlerweile vor, die Erwähnung dieses gesamten POSIX-Standards, der sowieso völlig veraltet ist und mit richtigen unixoidaloösen Systemen (zB cygwin) nichts zu tun hat, rauszunehmen und durch einen Link auf Microsoft zu ersetzen. Windows Home ist sowieso viel verbreiteter und so kann man die Erwähnung der Marke UNIX elegant umgehen. --bakunin (Diskussion) 05:50, 24. Mai 2019 (CEST)

Ich habe es jetzt nochmals geändert. Ich habe Unix und Betriebssystem verlinkt, sowie UNIX Version 7. Unix-artig kommt nun ebenfalls getrennt vor. Ich hoffe, dass SUS und POSIX so nun passt. Die Beispiele sind eindeutig als Beispiele erkennbar (Einleitung mit "darunter *BSD, Linux", also nicht exklusiv und nicht vollständig), und dass sie sich weitgehend an den mit POSIX festgelegten Standard für das Nullgerät halten.

‣Andreas•⚖ 13:27, 26. Mai 2019 (CEST)

Dieser Satz:

Seinen Ursprung hat /dev/null im Betriebssystem UNIX Version 7 von 1977 und dessen Verhalten wurde im POSIX-Standard festgelegt.

enthält einen falschen Bezug, denn das "dessen" bezieht sich jetzt auf UNIX Version 7 und nicht mehr auf /dev/null. Entweder ersetzt du "und dessen" durch ", sein" oder durch "und sein" oder du machst überhaupt Zwei Sätze daraus.

Da ich übrigens mehrmals von dir gelesen habe, daß "POV" vermieden werden sollte, solltest du wertende Adjektiva wie "unzählig" ebenfalls überdenken - ganz davon abgesehen, daß die "unzähligen Linux-Distributionen" doch alle denselben Kernel verwenden, der das /dev/null implementiert. Das ist doch keine Leistung der Distribution, oder?? --bakunin (Diskussion) 09:00, 27. Mai 2019 (CEST)

Doch, denn wie du ja selbst richtig argumentiert hast, kann ich nicht alle Unixe – und damit alle Linux-Distributionen – abklappern und auf die Existenz von /dev/null prüfen. Jede Linux-Distribution konfiguriert im Normfall einen Standard-Kernel, der von der Distribution abhängt. Es kann zwar auch der Nutzer einen eigenen Kernel verwenden, der ist dann aber nicht mehr von der Distribution. Das Adjektiv "unzählige" habe ich deswegen gewählt, weil man sie unmöglich zählen kann - und es ist mir noch nie eine untergekommen, die /dev/null nicht gehabt hätte, aber es gibt vielleicht eben doch welche, die kein Nullgerät haben. Im Kernel muss dazu nämlich devfs aktiviert sein, ob udev auch vonnöten ist, weiß ich nicht. Ohne devfs muss man die device-nodes wie früher selbst erstellen - auch wieder Sache der Distribution. Und auch hier gilt wieder: wenn ein Anwender (SysAdmin) das umkonfiguriert, ist es ja nicht mehr die ursprüngliche Distribution.

‣Andreas•⚖ 10:24, 27. Mai 2019 (CEST)

Befehlserklärungen

Soweit ich weiß, ist die Wikipedia kein Lehrbuch. Erklärende Hinweise für Kommandos - noch dazu solche, die für den Artikel selbst keine Rolle spielen, wie cp - sind deshalb zu unterlassen. Sollte eigentlich jemand, der die Wikipedia als sein Privateigentum betrachtet und sich anmaßt, darüber zu befinden, wer hier schreiben soll und wer nicht, wissen.

Das wurde bis jetzt anders gehandhabt. Viele Artikel beinhalten ein einfaches Beispiel, um die Funktion oder die Verwendung zu veranschaulichen. Das ist es, was ein Beispiel ausmacht.

Wie würdest du es sonst machen? Ein Bild spricht mehr als 1000 Worte – ein Beispiel auch, denn es erklärt anschaulich die Funktion und eine mögliche Verwendung.

‣Andreas•⚖ 12:28, 19. Mai 2019 (CEST)

Es geht nicht um das Beispiel selbst, sondern die Erklärung dafür, wie der cp-Befehl funktioniert. Wenn das jemand interessiert, dann soll er unter cp nachsehen, aber die Erklärung, was genau "Quelle" und "Ziel" ist, hat dort jedenfalls nichts verloren und das ist auch nicht "weit verbreitet". --15:29, 22. Mai 2019 (CEST)

Erl. ‣Andreas•⚖ 18:28, 22. Mai 2019 (CEST)

Prompt hinzugefügt

Ein Prompt ist ein Bestandteil der Oberfläche einer Shell und steht mit dem Befehl, der hier als Beispiel angeführt wird, in keinerlei Zusammenhang. Aus dem Grund sollte er wieder entfernt werden.

Erl. ‣Andreas•⚖ 12:20, 19. Mai 2019 (CEST)

--bakunin (Diskussion) 22:49, 16. Mai 2019 (CEST)

Fremdwörter raus

Und noch ein Nachschlag: Wenn schon Fremdwörter raus sollen und "device" deshalb nicht tragbar ist, dann bitte auch die "Implementierung" in "Einbau" verbessern - ganz abgesehen davon, daß es "Implementation" und nicht "Implementierung" heißt. Die "Gerätedatei" sollte genauer spezifiert werden, schließlich ist es eine zeichenhingewendete Gerätesachverhaltsansammlung. --15:54, 22. Mai 2019 (CEST)

Das wäre eine Übertreibung. Wir sollten deutsche Wörter verwenden wo es sie gibt und wo sie auch in der Fachpresse Einzug gehalten haben. Bei Implementierung ist dies der Fall, siehe den entsprechenden Artikel. ‣Andreas•⚖ 13:28, 26. Mai 2019 (CEST)

/dev/null ist ein "character-oriented device", darüber besteht wohl wenig Diskussionsbedarf. Wenn du diesen Begriff schon unbedingt übersetzen mußt und für "device" "Gerätedatei" schreibst, dann kannst du "character-oriented" entweder unübersetzt lassen, also: character-oriented Gerätedatei oder es eben auch übersetzen, dann sind wir genau bei der von mir vorgeschlagenen zeichenhingewendeten Gerätedatei oder - wenn man das lateinischstämmige "Datei" auch übersetzt, bei der zeichenhingewendeten Gerätesachverhaltsansammlung (eventuell auch zeichenhingewendeten Gerätesachverhaltsdarstellungsansammlung). Such dir was aus, ich finde die alle gleich gut.

Oder, alternativ, halten wir endlich fest, daß es hier gar nicht um "Fremdwörter" geht (wie immer behauptet wird), sondern - ausschließlich um Anglizismen! Fremdwörter sind nämlich völlig in Ordnung, solange sie griechisch, lateinisch, französisch (gehst du morgens ins Büro oder in die Arbeitsstube?) oder sonstwie sind. Nur Englisch, das dürfen sie auf keinen Fall sein, weil es nämlich sonst für die Laien unverständlich wird, die zwar alle fließend Latein und Altgriechisch können, aber des Englischen üblicherweise nicht mächtig sind. --bakunin (Diskussion) 08:45, 27. Mai 2019 (CEST)

Andere Baustelle. Ich bin zwar deiner Meinung, aber dazu müssten wir erstmal den Artikel Gerätedatei ordentlich aufräumen. Und für die Übersetzung brauchen wir Quellen, die es vielleicht gibt – oder eben auch nicht. Aber eigenmächtig will ich hier nicht übersetzen – mit der Ausnahme, dass man es in Klammern vorsichtig formuliert, etwa /dev/null ist ein englisch character-oriented device (was auf Deutsch in etwa einer zeichenorientierten Gerätedatei entspricht). Aber das würde ich in diesem Fall niemals machen, denn entweder es gibt eine entsprechende deutsche Übersetzung in der Fachpresse – die dann aber auch in den Artikel Gerätedatei muss und mit der ich mich hier gar nicht allzusehr aufhalten würde – oder eben nicht, und wir verbleiben englisch – auch ebenfalls wieder concur mit dem Artikel Gerätedatei.

Kannst du das verstehen, akzeptieren, damit leben?

Wenn du da etwas an deutschen Fachbüchern weißt – bitte teile diese Quellen!

‣Andreas•⚖ 10:37, 27. Mai 2019 (CEST)

"Eingabe"??

Was soll eigentlich der Verweis auf "Eingabe", wenn es um das Lesen von /dev/null geht? Das Lesen einer Datei ist das Lesen einer Datei - Punkt. Das Lesen aus /dev/null unterscheidet sich in keiner Weise vom Lesen aus irgendeiner anderen Datei. --bakunin (Diskussion) 05:59, 24. Mai 2019 (CEST)

Das erscheint angemessen, da es sich bei /dev/null um ein Eingabegerät handelt. Zitat aus dem Artikel Eingabe (Computer) (2. Absatz): "Die Eingabe erfolgt entweder direkt über ein Eingabegerät wie Maus oder Tastatur, oder es werden Daten aus einer Datei eingelesen oder über ein Computernetz von einem anderen Computer übertragen."

Das ist hier der Fall. Für jemanden, der sich wundert, bei Lesezugruff auf Speicherzugriff zu landen, ist das eine hilfreiche Addition.

‣Andreas•⚖ 13:31, 26. Mai 2019 (CEST)

Sorry, aber deine Prämisse ist falsch: /dev/null ist mitnichten ein "Eingabegerät", sondern eine - ganz normale - Datei. Es kann (bzw. sein Inhalt kann) als Eingabe fungieren, aber das ist nicht dasselbe: eine Handgranate kann auch als Briefbeschwerer fungieren, aber im Lemma "Briefbeschwerer" wirst du trotzdem keine Handgranaten erwähnt finden. --bakunin (Diskussion) 11:26, 27. Mai 2019 (CEST)

So ganz normal ist diese Datei dann aber doch nicht... character special device (/dev/null wird auch oft als pseudo device bezeichnet).

Quelle von IBM für AIX: /dev/null und Special Files

Da ist von device drivers die Rede, also von Gerätetreibern... Bei Eingabegeräten (wenn /dev/null gelesen wird) ist das dann also ein Eingabegerät. Dass diese in UNIX eine special device file werden, haben wir doch schon geklärt (Everything is a file).

‣Andreas•⚖ 12:40, 27. Mai 2019 (CEST)

Das File wird von einem Device Driver erzeugt, ja. Aber - und das ist das Wichtige bei UNIX, nämlich eben das, was das Prinzip "everything is a file" bedeutet: egal, wie dieses File erzeugt wird (wie, sozusagen, sein "Backend" beschaffen ist), es ist nach "außen" (also wenn man daon liest, in es schreibt, ...) ein ganz normales File! Das bedeutet insbesondere, daß du jedes System Call (fopen(), fclose(), ftell(), fskip(), ....) verwenden kannst, ohne dich darum kümmern zu müssen, was das genau ist und wie/von wem es gemacht ist! Das ist eben kein "Eingabegerät", sondern ein File, das - für den lesenden Prozeß - "zufälligerweise" von einem Device driver gefüllt wird. Würde derselbe Prozeß von irgendwoanders lesen, dann wäre für ihn keinerlei Unterschied merkbar. --bakunin (Diskussion) 14:25, 28. Mai 2019 (CEST)

Aus diesem Blickwinkel hast du natürlich Recht. Aber, wenn ich die Quelle von IBM für AIX zitieren darf:

Special files, at first glance, appear to be just like ordinary files … However, there is an important difference between the two.

Das alleine macht wohl einen Hinweis darauf, dass es sich eben nicht einfach um eine Datei wie jede andere handelt, notwendig.

An ordinary file is a logical grouping of data recorded on disk. A special file, on the other hand, corresponds to a device entity.

Es sagt ja keiner, dass das nicht stimmt. IBM schreibt genau dasselbe. Aber zufälligerweise schient es nicht zu sein...

Ein Hinweis auf corresponds to a device entity im Sinne eines Eingabegeräts – also einer Eingabe (Computer) – erscheint mir damit als durchaus sinnvoll, mit dem Argument, dass die character special file /dev/null als Eingabegerät fungiert, womit die Verlinkung schließlich begründet ist.

‣Andreas•⚖ 01:06, 29. Mai 2019 (CEST)

Also nochmal: ja, natürlich ist zwischen einem Device file und einem "normalen" File ein Unterschied. Aber - und das ist der Punkt, wenn du auf die Eigenschaft kann als Eingabe fungieren abstellst, eben nicht! Es ist auch zwischen einem Stahlblech und einem Brückenpfeiler ein Unterschied - aber wenn du auf die Eigenschaft ist aus Stahl abstellst, dann eben nicht! Die ist nämlich beiden gemein! Es würde aus demselben Grund auch falsch sein, in einem Satz mit "Stahl" auf "Brückenpfeiler" zu verlinken. Aus dem Umstand, daß /dev/null - so, wie jedes andere File auch - als Eingabe für was auch immer verwendet werden kann, folgt noch nicht, daß es ein "Eingabegerät" ist. Gerade, wenn du es als Eingabe verwendest, dann bedienst du dich eben nicht seiner Eigenschaft als "device file", sondern nur einer Eigenschaft, die es mit jedem anderen File - nämlich, daß man daraus lesen kann - teilt. Du kannst mit einer Bratpfanne jemanden erschlagen, aber deshalb wird "Bratpfanne" nicht unter "Mordwerkzeug", sondern dennoch unter "Kochgeschirr" geführt. Daß man damit jemanden erschalgen kann, hat nichts mit der Eigenschaft "Pfanne", sondern nur mit seiner Masse zu tun und diese Eigenschaft teilt die Pfanne mit allem möglichen anderen: Ziegelsteine, Baseballschläger, Bügeleisen, ... --bakunin (Diskussion) 11:16, 3. Jun. 2019 (CEST)

Du magst recht haben, doch ist die Eigenschaft von /dev/null eben auch jene, einerseits ein definiertes Ausgabegerät und andererseits ein definiertes Eingabegerät zu sein. Zwar ist das Nullgerät ein virtuelles Gerät, doch als character device verhält es sich eben doch wie jedes andere, echte, I/O-Device. Da alle Geräte unter Unix über eine spezielle Datei repräsentiert sind, ist /dev/null hier keine Ausnahme, wenn auch im Kernel als virtuelles Gerät realisiert.

Ja, wenn ich /dev/null lese, erhalte ich dasselbe Ergebnis als wenn ich eine leere Datei lese: EOF. Das kann man vermutlich auch über ein leeres Band in einem Bandlaufwerk sagen: auch da erhält man u.U. einfach ein EOF zurück, wenn das Band leer ist.

Was ist hier die Kernaussage? Dass es, weil es eine Datei ist, nicht gleichzeitig ein – wenn auch virtuelles – Gerät sein darf? Warum nicht?

‣Andreas•⚖ 17:23, 3. Jun. 2019 (CEST)

Die Kernaussage ist, daß das keine Eigenschaft von /dev/null und auch keine Eigenschaft eines "virtuellen Devices" und ebenfalls keine Eigenschaft eines Device Files allgemein ist, sondern: eine Eigenschaft, die jedes File hat! Hier sind noch ein paar andere Aussagen, die unzweifelhaft richtig sind:

Das characterorientierte virtuelle Device file /dev/null wird bei der Ausgabe von ls angezeigt.

Das characterorientierte virtuelle Device file /dev/null kann mit dem Kommando cp kopiert werden.

Wenn man die nötigen Berechtigungen hat, kann man es löschen.

Der letzte Buchstabe des Namens wird bei der Ausgabe durch den Buchstaben l repäsentiert.

Alles das sind sachlich zutreffende Aussagen, aber die gelten eben für jedes File, bzw. im letzten Fall für absolut jeden Buchstaben "l" und nicht nur für /dev/null! Und aus diesem Grund haben sie in dem Artikel nichts verloren. Die Tatsache, als Eingabe dienen zu können, ist eben KEINE Eigenschaft, die "/dev/null" hat, sondern die alles hat, was eine Datei ist. Aus demselben Grund wird zwar erwähnt, daß man /dev/null als Ausgabeziel für zu verwerfende Daten nehmen kann (das ist bei /dev/null so), aber nicht, daß man es allgemein als Ausgabeziel verwenden kann (eine Eigenschaft, die es mit jeder anderen Datei teilt). Natürlich hat /dev/null - wie jede andere Datei, denn es ist ja eine Datei - alle Eigenschaften, die Dateien im Allgemeinen zukommen, aber die sollten im Artikel "Datei" (oder wie auch immer er heißen soll) richtig, nicht im Artikel über diese ganz besondere Datei. Da sollte das reinkommen, was sie von anderen Dateien unterscheidet, nicht das, was sie mit allen anderen gemein hat. --bakunin (Diskussion) 10:23, 7. Jun. 2019 (CEST)

Ja. Und darf ich dann auf eine Datei verlinken, wenn es eine Datei ist?

Darf ich sagen, dass es dies tut, wenn es als Ausgabe fungiert, und jenes, wenn es als Eingabe fungiert? Denn was /dev/null von anderen Dateien und Geräten (devices) unterscheidet, ist ja, dass es eine definierte Eingabe und Ausgabe hat. Die meisten Dateien als auch die meisten E/A-Geräte (I/O devices) - was ja bei Unix fast immer dasselbe ist: ein E/A-Gerät ist ja auch eine spezielle Datei – haben ja nicht ein in diesem Maße vorhersehbares Verhalten...

Ich verstehe nicht, warum du dich daran stößt, /dev/null auch als Gerät zu sehen. Was ist daran so falsch? Und es wird ja nicht erklärt, was ein Lesezugriff bzw eine Eingabe genau ist – es wird bloß darauf verlinkt!

‣Andreas•⚖ 14:50, 7. Jun. 2019 (CEST)

OK, nochmal von vorne, denn scheinbar reden wir aneinander vorbei:

Ich stoße mich nicht daran, "/dev/null auch als ein Gerät zu sehen" - abgesehen davon, daß es eben kein Gerät ist, aber das hatten wir schon.

Ich stoße mich daran, es als "Eingabegerät" zu bezeichnen, weil es das eben nicht ist (auch dann nicht, wenn man einen hinreichend unscharfen Begriff von "Gerät" zugrundelegt, sodaß die Bezeichnung "Gerät" gerechtfertigt wäre). Der Grund ist, daß ein "Eingabegerät" eine besondere Form eines "Geräts" ist: nämlich eine, deren definierende Eigenschaft es ist, Eingaben zu erzeugen (oder zu ermöglichen, ...). Beispielsweise ist dies bei einer Tastatur, einer Maus, einem Lochkartenleser, etc.. der Fall: diese Geräte sind - vornehmlich - dafür gebaut, Eingaben für den Rechner zu erzeugen. Hingegen hat "/dev/null" eben diesen definierenden Zweck, nämlich Eingaben engegenzunehmen, zu produzieren, weiterzuleiten, ... NICHT. Als "Eingabe" für irgendwas anderes verhält es sich lediglich wie jede andere (leere) Datei auch. Und die Eigenschaft, überhaupt als Eingabe für irgendwas fungieren zu können, hängt weder mit einer speziellen Eigenschft von /dev/null selbst, noch mit seiner Eigenschaft als "Gerät" zusammen, sondern damit, daß es eben (auch) eine Datei ist und jede Datei als Eingabe fungieren kann. Du kannst auch die Datei /usr/bin/ls (also das Binary) als Eingabe verwenden ( cat < /usr/bin/ls ist ein völlig legaler Befehl), aber trotzdem wird diese Eigenschaft nicht in dem Artikel ls (Unix) erwähnt. Warum, glaubst du, wohl?

Aus demselben Grund werden Ziegelsteine auch nicht als "Briefbeschwerer" geführt, selbst dann, wenn man sie unzweifelhaft als Briefbeschwerer verwenden kann: es ist nicht ihr definierender Einsatzzweck und als Briefbeschwerer kann man sie nur insofern verwenden, wie man alles andere mit einer vergleichbaren Masse bzw. Dichte verwenden kann. --bakunin (Diskussion) 11:40, 13. Jun. 2019 (CEST)

Ich danke dir für deine Ausführungen. Aber ich bin leider doch der Meinung, dass /dev/null weit öfter als Eingabequelle verwendet wird als z.B. /usr/bin/ls (auf meinem System übrigens /bin/ls). Es ist ja gerade das schöne, dass man mit /dev/null ein EOF erhält, sodass es oft und gerne verwendet wird, um leere Eingaben zu produzieren. Auf Ebene der Unix-Shell ist /dev/null dafür eine zuverlässige Adresse. Sonst müsste man den Anwender bitten, eine leere CD-R einzulegen... Nein, im Ernst: cp /dev/null "leere Datei.txt" ist eine legitime und auch verwendete Art, eine Datei zu erstellen. touch "leere Datei.txt" wäre eine weitere ebenfalls häufige Art, wie auch cat /dev/null > "leere Datei.txt". Und gerade weil das so ist, fungiert /dev/null eben nicht nur als virtuelles Ausgabegerät "Schwarzes Loch", sondern auch als Eingabegerät "leere Eingabe" i.e. EOF. Und, ganz ehrlich, wieviele andere Dateien kennst du auf einem Unix-System, die zuverlässig ein EOF liefern?

Von IBM, AIX 7.1: cp /dev/null /var/adm/wtmp The log will grow indefinitely unless system accounting is running. System accounting clears it out nightly.^Ref

Bei "cp /dev/null /Pfad/mit/Datei.Erweiterung" (oder mit cat) wird die Datei, wenn sie bereits existiert, auf eine leere Datei zurückgesetzt, was mit touch ja nicht geht.

Zugegeben, /dev/null wird zu 99,99% dazu verwendet, Ausgaben zu unterdrücken. Das Kommando grep -Rw "/dev/null" /usr/* zeigt dies eindrucksvoll (aber unübersichtlich).

Deinen Vergleich kann ich deshalb nicht akzeptieren, weil die Datei/das Gerät als Eingabe eine fest definierte Funktion von /dev/null ist – und, wie ich ja bereits verlinkt habe, auch Verwendung findet, wenn auch deutlich weniger als die Funktion Ausgabe. Auch, wenn sich /dev/null bei der Eingabe wie jede andere leere Datei auch verhält - in der Kombination von Ein- und Ausgabe eben gerade nicht. Keine andere gibt weiterhin zuverlässig ein EOF zurück, wenn davor eine Ausgabe darin geladet ist. Damit verhält sich /dev/null bei der Eingabe, in Kombination mit der Ausgabe, besonders und nicht wie jede andere (anfänglich) leere Datei auch.

‣Andreas•⚖ 21:27, 13. Jun. 2019 (CEST)

File mit Datei zu übersetzen...

@Bakunin: Es betrifft deine Änderung mit der Zusammenfassung: "File" in "Datei" zu übersetzen ist Unsinn, denn ein "File" kann auch ein FIFO oder sonstwas in einem "Filesystem" sein, während eine "Datei" eben nur eine Datei ist.

Damit komme ich nicht zurecht, denn im Artikel Datei werden ja spezielle Dateien (Pseudodateien) im Abschnitt Arten von Dateien beschrieben. Das sind somit Dateien. Auch im Artikel file steht als BKL ganz oben: Dieser Artikel behandelt den Unix-Befehl file. Hingegen ist der Anglizismus File gleichbedeutend mit Datei.

Somit kann man File mit Datei übersetzen, weil das, was du kritisiert, im Deutschen eben auch inkludiert ist. Oder sind die entsprechenden Artikel etwa falsch?

Und, wenn wir es schon soooo genau nehmen, dann ist die Formulierung auch Unsinn, denn bei einem Befehl muss keine Datei, sondern ein Referenz, also zumindest ein Dateiname (mit oder ohne Pfad darauf im Dateisystem), angegeben werden. Der Satz müsste also korrekterweise so lauten:

… um beim Befehl grep die Ausgabe des Dateinamens in den Ergebnissen zu erzwingen muss mehr als ein Dateiname als Kommandozeilenparameter angegeben werden.

‣Andreas•⚖ 12:45, 2. Feb. 2021 (CET)

Verbreitet Bakunin wieder bzw. noch immer seinen allen Quellen widersprechenden religiösen Wahn, ja? Datei ist die Übersetzung von file. Datei wird nicht nur bei regular file sondern bei jedem Typ (type) angewandt. LG, ℳ웃79 16:01, 2. Feb. 2021 (CET)

@Bakunin: Ich habe deine Änderung von Datei → File abermals rückgängig gemacht.

Du schreibst: Ein FIFO, ein Device File, eine Process Substitution sind alles eben KEINE Dateien, auch wenn einige davon einen Eintrag im Filesystem haben. Das kann ich nicht bestätigen. Im Gegenteil:

• Dateiarten hier und hier: Eine nähere Betrachtung zeigt jedoch, dass UNIX zwischen sechs Arten von Dateien (Files) unterscheidet: Gewöhnliche Dateien, Dateiverzeichnisse (Directories), blockorientierte und zeichenorientierte Gerätedateien, FIFO-Dateien und Symbolische Links.

Was du hingegen mit process substitution meinst, ist mir gerade nicht klar. Eine Pipe?

In Summe bedeutet das, dass ich dich bitte, zuerst hier (auf der Diskussionsseite) die von dir gewünschte Änderung zu belegen. Bei einem Konsens kannst du es dann umsetzen, wenn nicht, dann aber nicht.

‣Andreas•⚖ 09:07, 12. Apr. 2021 (CEST)

@Bakunin: Bitte beteilige dich an der Diskussion und beachte WP:WAR. "Datei" ist Deutsch und die Übersetzung von "file" aus dem Englischen, ein Datenstrom ist etwas anderes (einen kontinuierlicher Fluss von Datensätzen). --BlauerBaum (Diskussion) 10:40, 13. Apr. 2021 (CEST)

Datei ist nicht deutsch, sondern - datum lateinisch. Darüber hinaus habe ich gesagt, daß zB eine process substituition eben KEINE Datei ist, sondern ein "Datenstrom". Eben, weil es ein Datenstrom und keine Datei ist, wird es durch die Bezeichnung "Datei" nicht erfaßt. Das sollte selbst jemand begreifen, dessen Hauptleistung darin besteht, die von mir angeführten Belegstellen und Fußnoten aus den Artikeln rauszulöschen und mir dafür "religiösen Wahn" vorzuwerfen. Beleidigungen dieser Art habe ich nicht nötig, aber die läßt Y2kbug, der so äußerst penibel ist, was die Vorschriften für mein Verhalten angeht, kommentarlos durchgehen.

PS: Da du den Unterschied zwischen "process substitution" und "pipe" nicht kennst, empfehle ich dir irgendein Anfängerbuch über Shell-Programmierung. Ich sehe meine Aufgabe als - von Messerjokke festgestellter "religiöser Wahnsinniger", siehe oben - nicht darin, jenen Leuten Nachhilfeunterricht zu erteilen, die ich dann für einen Edit um Erlaubnis fragen muß.

--22:14, 17. Mai 2022 (CEST) (unvollständig signierter Beitrag von Bakunin (Diskussion | Beiträge) )

Ja, danke für den Hinweis, werde ich bei Zeiten machen: mir ein Anfängerbuch über Shell-Programmierung zu Gemüte führen.

Allerdings sehe ich im Artikel weder process substitution noch pipe verwendet. Bleibt die Kritik, dass Ein FIFO, ein Device File, eine Process Substitution sind alles eben KEINE Dateien, auch wenn einige davon einen Eintrag im Filesystem haben falsch ist – zumindest bei device file, denn das ist belegt eine Art von Datei, was auf /dev/null zutrifft und – daher – auch deine Änderung (von vor > 1 Jahr) in der Kritik steht und diskutiert wird. 1. dass wir dt. "Datei" und nicht engl. "File" verwenden, haben wir ja schon diskutiert. Und 2. nimmt grep (und viele andere Unix-Kommandos) schon Dateien als Eingabe an, was z.B. in Form von einer Angabe als Dateiname sein kann, oder als redirect, als pipe, oder eben als process substition. In allen Fällen erscheint die Eingabe für das jeweilige Kommando aber wie eine Datei, was der springende Punkt ist.

Also: Sollte process substitution im Artikel zum Thema werden, werde ich mich auf deine fachliche Expertise verlassen und darauf vertrauen, dass du gute Quellen bringen kannst, die das, was dann in den Artikel kommt, gut belegen. Für die Datei /dev/null ist das jedoch im Moment nicht das Thema, oder?

‣Andreas•⚖ 00:20, 18. Mai 2022 (CEST)

/dev/null als Ziel für stderr

Ich persönlich nutze /dev/null am häufigsten um (bspw. in einem Shell-Skript) uninteressante Fehlermeldungen wie bspw. "Datei nicht gefunden" verschwinden zu lassen, wenn der betreffende Befehl keine "sei still"-Option hat.

Beispiel: if [[ `ls *.ctrl 2>/dev/null | wc -l` > 0 ]]; then echo "Control-Datei gefunden"; fi

Weitere Beipiele wären Aufrufe von grep, mv oder cp.

Gibt es Gegenstimmen, dieses Nutzungsbeispiel mit aufzunehmen in den Artikel? --el_schalo (Diskussion) 08:45, 4. Okt. 2023 (CEST)

Bessere Beispiele wären find / -name needle 2>/dev/null, um Fehlermeldungen wie "permission denied" zu unterdrücken, oder if command -v pandoc >/dev/null; then echo "pandoc ist installiert"; fi. Dein Beispiel ist nicht idiomatisch und sollte lieber so geschrieben werden:

for file in *.ctrl; do
	if [ -e "$file" ]; then
		echo "Control-Datei oder -Ordner gefunden"
		break
	fi
done

Dexxor (Diskussion) 09:50, 4. Okt. 2023 (CEST)