Wie unterscheidet sich die Ordnerstruktur?
Nur geringfügig, insgesamt ist alles deutlich aufgeräumter und pragmatischer nach Zweck sortiert.
etc, var und tmp liegen unterhalb von /private/ statt im Root, aber da es dort entsprechende Sysmlinks dafür hat - für dich Banane.
Der Homeordner von root liegt nicht bei /root, sondern /private/var/root
(Die private Gruppe von root mit GID 0 heisst nicht 'root', sondern BSD-typisch 'wheel')
Ausserdem werden alle anderen Benutzerordner unterhalb von /Users/ angelegt - /home bleibt als impliziter Mountpoint für automount-NFS-Strukturen reserviert.
Dynamisch durch den lokalen Automount-Daemon (diskarbitrationd) eingehängte Volumes landen grundsätzlich unterhalb von /Volumes - analog zu /home bleibt auch /mnt ein reserviertes Tabu für dich.
(Der Inhalt von /Volumes/ wird im Finder durch die dort "auf dem Desktop" angezeigten Geräte reflektiert.)
Mit "low level" Mount-Tools, Dateisystemcheckern, Loopdevices usw kommunizierst do ohnehin fast niemals direkt, für solche Aufgaben gibt es einige wenige, extrem geschmeidig abstrahierende und überaus mächtige Wrapper-Utilities.
(Nur noch zwei zur Benutzerinteraktion bestimmte Hi-Level Kommandos ersetzen etwa drei bis fünf Dutzend der typischen GNU-Tools, dagegen wirken selbst Toolkits wie parted oder loconfig wie sehr frühes DOS.)
Die Vorlagen für Nutzerordner finden sich nicht unter /etc/skel, sondern in /System/Library/User Template/
(Dort findet sich ein sprachunabhängiger Part, der jeweils mit den spezifischen Elementen der gewählten UI-Sprache zusammengemischt wird.)
Die Matritzen für Bootloader/Boothilfsdateien befinden sich nicht in /lib oder /usr/lib, sondern (nach Plattform organisiert) immer unterhalb von /usr/standalone/...
Die aktiv benutzten Kopien derselben landen nicht in /boot, sondern normalerweise in /System/Library/CoreServices/
(Der Name allein sagt wohl mehr aus als drei Seiten Erläuterung dazu)
Der Kernel liegt ebenfalls nicht in /boot, sondern im Root (/mach_kernel).
Eine init-Ramdisk existiert für gewöhnlich gar nicht. Eine (fast nie benötigte) Bootloader-Konfiguration steckt in /Library/Preferences/SystemConfiguration/
Dort liegen auch einige andere sehr maschinenspezifische, essentielle Configs wie zB die Profile (Umgebungen) für den Netzwerkstack.
Ein Kernelcache wird vollautomatisch gepflegt und liegt zusammen mit anderen unter /System/Library/Caches/...
Die "Module" dazu heissen "Systemerweiterung" bzw KEXT und finden in der Library (oder besser: in den Libraries) unter "Extensions" ihr Zuhause.
Naja, fürs erste... sollte das genügen?
welche besonderen Ordner gibt es zusätzlich oder abweichend unter Mac OS X?
Sehr viele was die "höhere" Ebene der GUI und der OS X-eigenen Laufzeitumgebungen wie zB Cocoa betrifft - allerdings nur sehr wenige wenn du dich rein im BSD-Layer (CLI / X11) bewegst. Dort findest du dich auch gut zurecht wenn du schon mal in FreeBSD reingeschnuppert hast.
Welche Besonderheiten sollte man kennen, wenn man als Linux-Kenner anfängt, unter Mac OS X an der Shell zu arbeiten?
"su" ist noch vorhanden, aber eher als Mumie. Benutze exklusiv das modernere "sudo" für höhere Privilegien.
Gerätebezeichner für Speichermedien sind nicht statisch, sie werden gänzlich dynamisch nach aktueller Verfügbarkeit zugeteilt.
Es gibt kein /proc oder /sys Pseudo-Filesystem, diese entsprechenden Infos besorgt man sich ggf über spezifische Utilities.
Sämtliche Dateien können einen optionalen "Resource Fork" besitzen, der ein wenig an zB die "multiple Filestreams" von NTFS erinnert. Im Terminal werden nahezu immer sämtliche Angaben aber nur für den grundlegenden "Data Fork" gemacht.
Das meint:
Eine Datei die dort zB mit Null Bytes angezeigt ist, muss deshalb noch lange nicht tatsächlich leer sein!
(Der Finder zeigt dagegen als Dateigrösse immer die Summe beider Forks an.)
Um CLI-Befehle ersatzweise nicht auf den Data-, sondern auf deren Resourcefork auszurichten gibt es folgende Hilfs-Konvention:
/Path/to/any/regular/FILE/..namedfork/rsrc
Diese lediglich auf den ersten Blick *vermeintlich* leeren Files werden dir relativ häufig unterkommen. Beispielsweise bei einem Finder-Alias, dessen Datafork gar nichts enthält, während sein wahrer Inhalt sich (traditionell) im Resourcefork befindet.
(Diese Aliase kannst du in der BSD-Schicht leider nach wie vor weder setzen noch auflösen. Ein uraltes Ärgernis.
Die in der CLI-Schicht eingesetzten und von anderen Unices gewohnten "Symlinks" funktionieren zwar auch im Finder und im Rest der GUI, diese kannst du dort aber nicht setzen, jedenfalls nicht mit normalen Bordmitteln... maleficio!
Diese bescheidene Situation gleicht in etwa den nervigen Problemen mit den proprietären Explorer-Verknüpfungen (*.lnk) und NTFS-Junctions von Windows, die aus Unix heraus ebenfalls nicht "greifbar" sind.)
Die Gruppenzugehörigkeit von Ordnern/Dateien hat in OS X eine weit weniger ausschlaggebende Bedeutung als in anderen Unices.
Entgegen der Angaben in manchen Manpages (die ohne Anpassung direkt aus anderen BSD Derivaten übernommen worden sind) gilt zB:
Ordner vererben ihre eigene Gruppe IMMER an neu erstellte Unterobjekte, es ist *kein* GUID-Bit dafür erforderlich!
(vergleichbar zu einer omnipräsent aktiven Mountoption "bsd_dirs" unter Linux)
Der Benutzer als auch die Gruppe "unknown" (oder "_unknown") mit jeweils einer UID/GID von 99 hat eine "magische" Sonderbedeutung. Nur der Superuser root sieht ihre wahre Identität - also "unknown".
Alle anderen Benutzerkonten meinen sich darin "selbst" zu erkennen.
Das meint:
Ein Ordner, eine Datei etc die dem User #99 gehört, scheint immer dir selbst zu gehören, egal als wer du auch immer gerade angemeldet bist. Du hast *immer* die vollen Rechte des Eigentümers daran. Für die Gruppe gilt analog das gleiche.
Für die gesamte Familie der "
Mac Extended ..." (aka "HFS+" oder "HFSX") Dateisysteme gibt es eine relativ ähnliche, besondere Mount-Option. Sie bewirkt, dass
sämtliche Objekte im jeweiligen Volume dem gerade darauf zugreifenden Benutzer zugeschlagen werden - so als wären sie alle auf die magische ID #99 gesetzt.
Nennt sich "Eigentümer ignorieren" bzw "owners disabled" und ist
standardmässig aktiv auf allen diesen Volumes, es sei denn...
...es handelt sich um das aktuell genutzte Startvolume, oder
...das Volume befindet sich als eine ganz gewöhnliche, "native" Partition auf der/einer "intern" verbundenen Platte (am integrierten, fest verbauten HD-Controller angeschlossen, also idR SATA/intern), oder
...das System selbst hat ausnahmsweise das Ausschalten dieser Option erzwungen, zB auf TimeMachine Backup-Platten.
Alle anderen Mac-Volumes werden (beim erstmaligen Kontakt damit) mit dieser
aktivierten Option geladen, was den problemlosen Dateiaustausch zwischen verschiedenen Rechnern gewährleisten soll.
Das betrifft insbesondere also sämtliche CD/DVDs, externen Festplatten, Flashmedien und auch aktivierte Imagedateien.
Nur Administratoren können diese Einstellung individuell und dauerhaft ändern - das gilt aber immer nur für das gerade laufende OS.
Nach speziellen Ablageorten für verschiedene Architekturen (32/64-Bit usw) zu suchen ist überflüssige Mühe.
OS X benutzt durchgängig ein Archiv-fähiges Binärformat (machO), das beliebig viele Sub-Versionen in einer einzigen Datei vereint. Bis auf extrem wenige Ausnahmefälle, bei denen sehr schlecht gemachte Ports von anderen Systemen vorliegen, findest du also keine solchen separaten Zweige vor, sondern nur einen einzigen mit solchen "Fat" oder auch "Universal" genannten Binaries darin.
Welche Spezialitäten und wichtigen Programme sollte man kennen?
Zur absoluten Pflichtlektüre (das "who-is-who" unter den "must knowns") zähle ich mal folgende man-pages:
- diskutil (alle Aktionen rund um Speichermedien/Disks/Volumes/partitionieren/formatieren/...etc pp...)
- hdiutil (selbiges, aber ganz speziell rund um das Thema "Imagedateien")
- alle Seiten rund um launchd, vor allem launchctl und launchd.plist (ein "booty call" für Fans von inittab, crontab und Co)
- pkgutil und verwandte Seiten (weil es auch noch was gänzlich anderes als apt oder rpm gibt)
Machen wirs kürzer: Schau einfach nach und nach bei allem mal rein, das irgendwie auf "...util" und "...ctl" endet.
Aber fang mit den obigen Disk-Utilities an, die wirst du sofort und am meisten benötigen.
Gibt es so etwas wie eine Repository-Liste?
Äähm. Da müsstest du jetzt etwas genauer ausführen was du damit *genau* meinst.
Anosnsten kann man aber mit brew auch einen Paketmanager fuer OS X installieren und damit weitestgehend auf die Standardpakete zugreifen. Wenn man das parallel zu den Xcode-Tools macht, sollte man allerdings sehr genau wissen, was man da macht.
