Unix oder Linux Kurse für Mac?

[magheinz]

@magheinz
irgendwo wird behauptet, dass eine komplette Installation von Mac OS X vollständig und in allen Teilen UNIX konform ist. SuSv3 und POSIX 1003.1 Konformität wird (IIRC) für die C API, die Shell Utilities und das Threading zugesagt. Das ist doch schon mal was.

Apple schreibt das ja auch so, verspricht aber im nächsten Satz gleich noch mehr. Wenn du mal so ein System mit ein paar unix/linux-kisten im Netz verheiraten musst dann merkst du was da für Probleme auftauchen.

Unix Zertifizierung
Leopard ist jetzt ein registriertes Open Brand UNIX 03 Produkt, das die SUSv3
 und POSIX 1003.1 Spezifikationen für die C API, Shell Dienstprogramme und
 Threads erfüllt. Da Leopard all Ihren vorhandenen Unix Code kompilieren und
 ausführen kann, lässt es sich in Umgebungen einsetzen, die vollständige
 Konformität voraussetzen - einschließlich Programmierungen, um die
 Kompatibilität mit vorhandener Software zu gewährleisten.

von apple/technology/unix
Und das ist eben gelogen.
Es lässt sich eben NICHT in Umgebungen einsetzen die vollständige Konformität voraussetzen.
z.B. ein inkrementelles backup mit standardtools wie z.B: rsync bei Verwendung von symlinks funktioniert nicht. Auch andere Unix-Backuptools haben keine chance soetwas inkrementell zu sichern.
apple verspricht halt gerne mehr als es halten kann. Ich erinnere da mal an die tolle Möglichkeit "alle Verbindungen blockieren" unter 10.5.0.

Die ganzen Linuxe mit ihren endlosen Gnuismen können das jedenfalls nicht von sich behaupten.

Das ist der Unterschied: Sie tun das nämlich nicht da sie wissen das es nicht stimmt. Wobei es auch POSIX-kompatible Linuxe gibt, aber das ist was anderes

Ob jetzt da der Unix Stempel drauf ist oder nicht, ist mir persönlich Wurscht, aber wenn an sich simple Skripte nicht portabel sein können, weil jedes Derivat sein eigenes Süppchen kocht, das ist bitter. Da ist so ne Leitlinie sicher nicht verkehrt und in manchen Umgebungen sogar unerlässlich.

richtig. deswegen sollte man wenn man scripte schreibt die eben nicht auf nur einem system laufen sollen sich an einige regeln halten.
z.b.:
bei Posix ist z.b. die kornshell pflicht -> keine bashscripte schreiben.
wenn aber so Grundlagen wie z.b. die symbolischen links nicht funktionieren, dann hat man halt ein Problem. es bringt ja nix das sie zwar in scripten funktionieren, wenn der user dann aber z.b. mit textedit auf eine Datei zugreift diese wieder kaputt gemacht werden. Da hat apple einfach noch was nachzubessern.

 

[below]

wenn aber so Grundlagen wie z.b. die symbolischen links nicht funktionieren, dann hat man halt ein Problem. es bringt ja nix das sie zwar in scripten funktionieren, wenn der user dann aber z.b. mit textedit auf eine Datei zugreift diese wieder kaputt gemacht werden. Da hat apple einfach noch was nachzubessern.

Das hat aber nichts mit Unix, sondern mit der Applikation TextEdit bzw. dem Foundation Framework zu tun

Alex

 

[maceis]

rsync mag für Dich ein Standartool sein, es ist aber weder Bestandteil der SuSv3 noch von POSIX (soweit ich weiß kommt das aus der samba suite).
Mit anderen Worten: Das Verhalten von rsync in SuSv3 oder POSIX Systemen ist nicht definiert. Ich wüßte auch nicht, dass das irgendwo von Apple oder sonst jemandem versprochen wurde.

Außerdem: Die Standard Shell in SuSv3 ist die sh (in POSIX meines Wissens ebenfalls).

 

[magheinz]

die ganzen programme wie vim, bash, perl etc. sind nicht unix, sondern GNU (GNU = Gnu's Not Unix!)

also weder vim noch perl sind gnu.

sprich ihr müsst auf gnu.org nachschauen. und dort findet man leicht heraus, dass sich die programme für die verschiedenen unixe kaum unterscheiden

Setz dich einfach mal ein ein Solaris und du wirst merken wie groß diese Unterschiede sein können.

abgesehen von versionsunterschieden, aber da diese programme schon so lange im betrieb sind, gibt es kaum mehr neue versionen, und wenn dann unterscheiden sie sich nur margina

Das ist noch unsinniger. Der Vergleich von vim6 und vim7 wurde dir ja schon nahegelegt.
anderes beispiel:
http://www.unixtop.org/dist/top-3.8beta1.tar.gz
schau die mal die datei CHANGES an.

. wen schon dann gibt es gleich neue programme, wie z.b. bourne-shell -> bourne-again-shell (bash),
v -> vim

hiermit kann ich ja noch leben (ich vermute du meinst vi->vim)

awk -> perl -> python etc.

aber hier wirds echt kritisch
Das sind 3 vollkommen unterschiedliche und unabhängige dinge.

der einzige unterschied ist die bedienung auf unterschiedlichen tastaturen, die interaktion mit anderen programmen (wie der shell), aber auch teilen des unterbaus des OS. Insofern gibt es unterschiede, ja, aber die liegen nicht am programm, sondern wirklich an den unterschieden der betriebssysteme.

Unfug, sorry. aber das ist einfach nicht war.
vergleiche einfach mal die manpages auf http://nixdoc.net

als populärstes beispiel sei hier \n, \r oder beides als zeilenende erwähnt

also die Zeichenkodierung usw ist jetzt nicht wirklich ein programm...

 

[magheinz]

rsync mag für Dich ein Standartool sein, es ist aber weder Bestandteil der SuSv3 noch von POSIX (soweit ich weiß kommt das aus der samba suite).
Mit anderen Worten: Das Verhalten von rsync in SuSv3 oder POSIX Systemen ist nicht definiert.

Das verhalten ist sehr wohl definiert. schliesslich nutzt rsync nur systemfunktionen um dateien zu kopieren.
aber nimm halt pax.
oder mach mit nem simplen skript ein inkrementelles backup nach dem motto:

for each file in directory
do
     copy file nach backup.0/
done

#inkrementeller durchgang
for each file in direktory
do
    if [file. mtime >$backup.0/$file.mtime]
     then
         copy $file nach backup.1/$file
     else
         hardlink  backup.0/$file backup.1/$file
     fi
done

wenn eine der zu sichernden datein ein symlink auf eine andere ist und zwischendrin in textedit geöffnet wurde habe ich sie jetzt doppelt im backup.
mag bei ner kleinen textdatei keine rolle spielen, bei nem dvd-image sieht das aber eventuell schon ganz anders aus.

rsync war nur ein beispiel für ein programm welches dateien kopiert.

ich wüßte auch nicht, dass das irgendwo von Apple oder sonst jemandem versprochen wurde.

Ich habs doch extra von der apple-seite zitiert:

[...]lässt es sich in Umgebungen einsetzen, die [b]vollständige
 Konformität voraussetzen[/b][...]

Außerdem: Die Standard Shell in SuSv3 ist die sh (in POSIX meines Wissens ebenfalls).

Posix schreibt korn vor. Deswegen liefert sie ja auch Microsoft bei den SFU mit aus. wikipedia behauptet auch das die ksh die richtige ist.
http://de.wikipedia.org/wiki/Unix-Shell#Die_Korn-Shell

Leider fehlt mir die möglichkeit in der original posix-spezifikation nachzuschauen.

ich persönliche bevorzuge eh die zsh

 

[maceis]

Du kannst aber in der SuSv3 nachsehen und da steh nun mal, dass die sh die Standardshell ist. Die ksh ist noch nicht einmal mandatory.

Ich bin außerdem der Ansicht, dass Du in die Unix-Zertifizierung Dinge hineininterpretierst, die sich daraus einfach nicht ableiten lassen.

Die Zertifizierung sagt z.B., dass Du, wenn Du mit den Shell Utilities arbeitest, dich auf ein genau definiertes Verhalten, eine definierte Systax und definierte Parameter verbindlich verlassen kannst. Du wirst dann ein genau definiertes Ergebnis erhalten.
Wenn Du einen ANSI konformen C Sourcecode mit einem ANSI C konformen Compiler bearbeitest, darfst Du Dich darauf verlassen, dass die Standard C Library mit einem genau definierten Funktionsumfang vorhanden ist. Dein Programm wird dann fehlerfrei kompilieren und auf eine genau definierte Art und Weise funktionieren.

Die Zertifizierung sagt definitiv nicht, dass Du mir beliebigen Programmen arbeiten und danach mit einem definierten Verhalten rechnen darfst.

Stell es Dir so vor. In einem Krankenhaus ist nur der aseptische OP Bereich steril, nicht aber die Eingangshalle, wo sich alles mögliche Gekreuch tümmelt. Setzt sich jemand aus der Eingangshalle auf den Operationstisch, kannst Du keine Antiseptik mehr erwarten.

Deine Forderungen sind etwa so, als wolltest Du in einem Krankenhaus, das ein Zertifikat für eine aseptischen OP Bereich hat, fordern, dass auch die öffentlichen Bereich gefälligst steril zu sein haben. Und wenn der Gärtner durch den OP latscht, dann hat der anschließend gefälligst immer noch steril zu sein.

 

[Dead_Eye_182]

so, einmal drüber schlafen und dann sollte das ganze schon viel besser gehen:

es gibt viele programme (wie z.b. cp), die in einem unix enthalten sind (ob es irgendwelche spezifikationen dazu gibt weiss ich nicht und interessiert mich auch nicht). wegen linzenz-querelen und zum teil doch recht beschränktem funktionsumfang machte sich die fsf/gnu daran, verbesserte eigene versionen dieser programme mit grösserem funktionsumfang (aber "rückwärts"-kompatibel) unter einer freien lizenz zu entwickeln, diese sind heute als sog. "GNU core-utils" bekannt. Diese sind in allen linuxen standardmässig dabei, allerdings nicht überall in der gleichen version.

Nun kann man schon sagen "UNIX ist nicht gleich UNIX", aber dann bitte auch nur die UNIX-teile davon vergleichen - und nicht mit GNU mischen.

so ist zum beispiel das oben bemängelte cp auf dem mac offensichtlich eine "original" unix version (ohne -a), siehe manpage:

STANDARDS
     The cp command is expected to be IEEE Std 1003.2 (``POSIX.2'') compatible.

HISTORY
     A cp command appeared in Version 1 AT&T UNIX.

während die fsf-version den -a modifier offensichtlich unterstützt (und noch einige andere), und sich im copyright-abschnitt deutlich als solche outet:

COPYRIGHT

       Copyright (C) 2005 Free Software Foundation, Inc.
       This  is  free  software.   You may redistribute copies of it under the
       terms	  of	  the	   GNU	    General	  Public       License

die gnu-coreutils sollten sich aber auf allen unix-kompatiblen systemen installieren (notfalls kompilieren) lassen, so dass man auf allen systemen den gleichen status quo herstellen kann.

ich hoffe ihr hasst mich nun nicht mehr so stark.

 

[maceis]

Also erstmal ein vorab: Mit Hass hat das Ganze gar nichts zu tun. Das ist eine sachliche Diskussion.

Ob es für 'cp' eine Spezifikation gibt oder nicht, kann Dir als Privatanwender freilich (fast) egal sein — es gibt natürlich eine. Das wird dann interessant, wenn Du beginnst Skripte zu schreiben, die auch auf anderen Systemen laufen müssen oder Skripte verwenden möchtest, die für andere Systemen entwickelt wurden (das ist ja auch das Thema dieses Threads)

Das die GNU Software "rückwärts"-kompatibel ist, ist eine Behauptung, die nicht zutrifft. Die sind ja gelegentlich nicht einmal untereinander kompatibel. Teilweise fehlte sogar eine vernünftige Versionierung, sodass man nur durch Auspropieren herausfinden konnte, was für eine Version man hatte. Manchmal sind auch die Parameter mit unterschiedlichen Funktionen belegt.

Insgesamt lassen Deine Ausführungen Zweifel aufkommen, ob Du überhaupt verstanden hast, worum es eigentlich geht. In manchen Umgebungen kommt es einer Katastrophe gleich, wenn ein Programm oder eine Library nicht so reagiert, wie es in den Spezifikationen steht.

 

[fromrussia]

Die Frage war nach Unix-Kursen für Mac User und draus wurde "Gibt es das *EINE* Unix".

In der Schule früher hieß es "Thema verfehlt, setzen, sechs". Wie wäre es wenn wir dem Fragesteller helfen anstatt uns unser gegenseitiges Wissen (das im Moment in dieser Tiefe aber garnicht gefragt ist) um die Ohren zu hauen.

Schönen Tag noch allerseits

W.

 

[marti]

Die Frage war nach Unix-Kursen für Mac User und draus wurde "Gibt es das *EINE* Unix".

In der Schule früher hieß es "Thema verfehlt, setzen, sechs". Wie wäre es wenn wir dem Fragesteller helfen anstatt uns unser gegenseitiges Wissen (das im Moment in dieser Tiefe aber garnicht gefragt ist) um die Ohren zu hauen.

Schönen Tag noch allerseits

W.

danke danke ihr habt mir ja schon viel geholfen.

Gruss
Marti

 

[maceis]

@fromrussia

Der Themenstarter hat schon in #14 signalisiert, dass seine Frage beantwortet ist.
Da sollte es doch niemanden weiter stören, wenn sich aus diesem nicht ganz uninteressanten Thema eine tiefergehende Diskussion entwickelt, zumal wir uns im Unix Fachforum befinden.

 

[Coliban]

Hmm, ich finde, dass die vielen verschiedenen, und teilweise widersprüchlichen, Aussagen aus einem Missverständnis herrühren. Es ist nun einmal so, dass es das eine "Standard Unix" eben nicht gibt. Es gab ungefähr bis in Jahr 1973/74 ein Unix und das aus dem Grunde, weil bis dahin von eben nur ein "Unix" in den Bell Labs entstanden ist, bzw. daran gearbeitet wurde (Ritchie, Kernighan, Canaday).

Die vielen verschiedenen Versionen von Unix rühren ja gerade aus der enormen Anpassungsfähigkeit und Versatilität des OS her.

Ich finde, dass es heutzutage eher eine philosophische Frage ist, was denn das "reine Unix" sei. Meines Erachtens gibt es eben kein "reines" Unix (auch wenn die Open Group die Markenrechte an dem Namen "Unix" hält).

mfg

p.s. ach ja, die Geschichte ist auch von den "Erfindern", bzw. der Firma nachzulesen: https://s3-us-west-2.amazonaws.com/belllabs-microsite-unixhistory/index.html
Und, auf ewig unvergessen: Digital Equipment (RIP)

 

[below]

Es ist nun einmal so, dass es das eine "Standard Unix" eben nicht gibt.

Soweit, so richtig. Es gibt aber Standards. Ob die dem TE helfen, ist eine ganz andere Frage.

Alex

 

[maceis]

Man könnte soweit gehen, zu behaupten, es gibt kein Standard Unix aber einen Unix Standard .

 

[Coliban]

Man könnte soweit gehen, zu behaupten, es gibt kein Standard Unix aber einen Unix Standard .

hehe, nicht schlecht

 

[magheinz]

"GNU core-utils" bekannt. Diese sind in allen linuxen standardmässig dabei, allerdings nicht überall in der gleichen version.

da ist so absolut gesagt nicht wahr.
z.b. im embedded-bereich wird vielfach die busybox eingesetzt die fast alle der GNU core-utils durch eigen Versionen ersetzt. z.b. auf meinem openwrt-router und meinem freerunner läuft die busybox.
Es gibt einige Linux-Distributionen die die GNU core-utils einsetzten, es sind aber bei weitem nicht alle!

 

[Zapfenzieher]

Man könnte soweit gehen, zu behaupten, es gibt kein Standard Unix aber einen Unix Standard .

Der war gut!

 

[maceis]

Kennt Ihr Schulze und Schultze? *ggg*

 

[quarx]

z.B. ein inkrementelles backup mit standardtools wie z.B: rsync bei Verwendung von symlinks funktioniert nicht.

Dann poste bitte mal ein nicht funktionierendes Minimalbeispiel. Ich kann hier problemlos mit rsync zwischen Linux und OS X hin- und hersichern, inkrementell und mit haufenweise Symlinks.

 

[magheinz]

Dann poste bitte mal ein nicht funktionierendes Minimalbeispiel. Ich kann hier problemlos mit rsync zwischen Linux und OS X hin- und hersichern, inkrementell und mit haufenweise Symlinks.

in #25 hab ich ein beispiel gepostet.
nicht rsync sondern cp. spielt aber keine rolle.