Auflösung von Systemordnern

[droptix]

In der Windows-Welt beherbergt das Betriebssystem sog. Systemordner. Um beim Scripten etwas unabhängiger von Laufwerksbuchstaben, Pfaden und Sprachen zu sein, gibt es viele dieser Ordner als Umgebungsvariable.

Die Variable %ProgramFiles% bezeichnet damit im Deutschen den Ordner "C:\Programme" und im Englischen "C:\Program Files". Das nette dabei ist, dass man sein Windows oder auch nur seine Programme auf einem anderen Laufwerk ablegen kann, sei es z.B. "D:\Programme". Solange Windows bescheid weiß, kann man in seinen Scripts fröhlich %ProgramFiles% verwenden und Windows löst die Variable dann in den korrekten Pfad auf.

Gibt es sowas auch unter Linux? Mit einem Ohr hab ich sowas schonmal gehört, aber bislang nichts bestätigt bekommen. Die Umgebungsvariablen meines Debian-Servers kann ich mir ja über `env` anzeigen lassen. Mein Home-Pfad steht da z.B. drin ($HOME). Das ist allerdings ein bissel wenig wie ich finde.

Um beim Scripten etwas Distributions-unabhängiger zu werden, müsste schon auf jedem Linux oder besser sogar jedem Unix-artigem System eine Art Tabelle solcher Systemordner existieren. Gibt es so etwas?

Windows geht systemintern sogar noch ein Stückchen weiter. Wer sich ein wenig mit .INF-Dateien beschäftigt (werden z.B. für Installationen und Deinstallationen verwendet), weiß dass Windows eine ganze Menge an Ordner-IDs kennt, die weitaus mehr Pfade als die in den Umgebungsvariablen definieren. Hier mal zur Info, was es alles gibt... ich suche unter Linux eben was Vergleichbares.

Value Destination Directory
01 SourceDrive:\pathname (the directory from which the INF file was installed)
10 Windows directory
This is equivalent to %windir%.
11 System directory
This is equivalent to %windir%\system32 for NT-based systems, and to %windir%\system for Windows 9x/Me.
12 Drivers directory
This is equivalent to %windir%\system32\drivers for NT-based platforms, and to %windir%\system\IoSubsys on Windows 9x/Me platforms.
17 INF file directory
18 Help directory
20 Fonts directory
21 Viewers directory
23 Color directory (ICM) (not used for installing printer drivers)
24 Root directory of the system disk.
This is the root directory of the disk on which Windows files are installed. For example, if dirid 10 is "C:\winnt", then dirid 24 is "C:\".
25 Shared directory
30 Root directory of the boot disk, also known as "ARC system partition," for NT-based systems. (This might or might not be the same directory as the one represented by dirid 24.)
50 System directory for NT-based operating systems

This is equivalent to %windir%\system (NT-based systems only).

51 Spool directory (not used for installing printer drivers − see Printer Dirids)
52 Spool drivers directory (not used for installing printer drivers)
53 User profile directory
54 Directory where ntldr.exe and osloader.exe are located (NT-based systems only)
55 Print processors directory (not used for installing printer drivers)
-1 Absolute path

16406 All Users\Start Menu
16407 All Users\Start Menu\Programs
16408 All Users\Start Menu\Programs\Startup
16409 All Users\Desktop

[roli]

Allaaf,

die Frage finde ich gut! Zuerst dachte ich, das ganze sollte 'n Witz sein, aber da du dir so viel Muehe gegeben hast, alle moeglichen und unmoeglichen Ordner/Variaben aufzulisten, gehe ich nicht (mehr) davon aus.

In der Windows-Welt beherbergt das Betriebssystem sog. Systemordner. Um beim Scripten etwas unabhängiger von Laufwerksbuchstaben, Pfaden und Sprachen zu sein, gibt es viele dieser Ordner als Umgebungsvariable.

Dir ist schon bekannt, das es doch recht grundsaetzliche Unterschiede zwischen Windows und Linux gibt, oder?
Linux kennt z.B. keine Laufwerksbuchstaben. Den ganzen Rest stellt man im Profile ein, sei es in dem des Users, oder im Systemweiten im /etc Verzeichnis.

Die Variable %ProgramFiles% bezeichnet damit im Deutschen den Ordner "C:\Programme" und im Englischen "C:\Program Files". Das nette dabei ist, dass man sein Windows oder auch nur seine Programme auf einem anderen Laufwerk ablegen kann, sei es z.B. "D:\Programme". Solange Windows bescheid weiß, kann man in seinen Scripts fröhlich %ProgramFiles% verwenden und Windows löst die Variable dann in den korrekten Pfad auf.

Stimmt schon, so macht Windows das, aber noch habe ich dein Problem nicht verstanden. "Was will'st du?"

Gibt es sowas auch unter Linux?

Wenn du nach %ProgramFiles% suchst, dann nein.

Mit einem Ohr hab ich sowas schonmal gehört, aber bislang nichts bestätigt bekommen. Die Umgebungsvariablen meines Debian-Servers kann ich mir ja über `env` anzeigen lassen. Mein Home-Pfad steht da z.B. drin ($HOME). Das ist allerdings ein bissel wenig wie ich finde.

Wass fehlt dir denn?

Um beim Scripten etwas Distributions-unabhängiger zu werden, müsste schon auf jedem Linux oder besser sogar jedem Unix-artigem System eine Art Tabelle solcher Systemordner existieren. Gibt es so etwas?

Wieder ein klares jein, es gibt die LSB (Linux Standard Base), in der definiert ist, welche Ordner es geben muss, un das darin zu liegen hat, damit ein System LSB konform ist.

Hier mal zur Info, was es alles gibt... ich suche unter Linux eben was Vergleichbares.

Value Destination Directory
...
17 INF file directory
...
50 System directory for NT-based operating systems
...
16406 All Users\Start Menu
16407 All Users\Start Menu\Programs
16408 All Users\Start Menu\Programs\Startup
16409 All Users\Desktop

Viel Spass beim suchen.

Jetzt mal Spass beiseite, wenn du dein Problem genauer beschreibst, kann dir sicher geholfen werden. Wenn du nicht etwas praeziser wirst, sollte es mich wundern, wenn du eine "brauchbare/hilfreiche" Antwort bekommst.

[droptix]

Hui sorry, hab ich mich so unklar ausgedrückt? Ich versuch's nochmal anders:

die Frage finde ich gut! Zuerst dachte ich, das ganze sollte 'n Witz sein

Räusper… nein, das ist kein Witz, sondern eine ernste Frage.

Dir ist schon bekannt, das es doch recht grundsaetzliche Unterschiede zwischen Windows und Linux gibt, oder?

Nein, das ist mir neu (Achtung: Ironie!) Aber ich habe leider nur den tieferen Einblick in Windows und suche nun was Vergleichbares unter Linux. Wieso, das erklär ich gleich noch…

Linux kennt z.B. keine Laufwerksbuchstaben. Den ganzen Rest stellt man im Profile ein, sei es in dem des Users, oder im Systemweiten im /etc Verzeichnis.

Aha, da tasten wir uns schon näher ran. Dass jeder User eine Art Profil hat ist mir bekannt. Allerdings bin ich auch da nicht sooo bewandert. Also schmeiß ich mal eben meine Debian-Kiste an… In meinem Home-Verzeichnis liegt nur eine Datei namens `.bash_profile`. Diese Einstellungen gelten z.B. nur für die Bash, hat aber nichts mit Systemordnern zu tun. Im Home-Verzeichnis war's das dann eigentlich auch schon. Schauen wir mal nach `/etc`. Die liegen viele .conf-Dateien, aber jede für spezielle Anwendungen. Dann noch `environment` oder `fstab` (da kriegt man zumindest schonmal den Root-Mountpoint raus, was in der Windows-Welt %windir% entsprechen dürfte). In `profile` wird nur $PATH zu den Binaries angepasst. Mehr kann ich erstmal dort nicht finden.

Die Variable %ProgramFiles% bezeichnet damit im Deutschen den Ordner "C:\Programme" und im Englischen "C:\Program Files". […] Windows löst die Variable dann in den korrekten Pfad auf.

Stimmt schon, so macht Windows das, aber noch habe ich dein Problem nicht verstanden. "Was will'st du?"

Ich möchte Skripte schreiben, die sich nicht auf einen statischen Befehl wie 'cp foo /home/droptix/foo' verlassen müssen. Vielmehr möchte ich das Home-Verzeichnis des Benutzers `droptix` irgendwo auslesen oder zumindest das allgemeine Home-Verzeichnis aller Benutzer auslesen. Würde man Umgebungsvariablen benutzen, hätte man sowas zur Verfügung: 'cp foo $HOME/droptix'. Wenn sich das globale Home-Verzeichnis mal ändert, funktioniert das Skript immernoch.

Wir hatten z.B. schonmal den Fall, dass wir eine zweite Festplatte nachgerüstet hatten, um alle Benutzerdaten von `/home` nach `/data/home` zu verschieben. Mit dem Befehl `vipw` kann man ja alle Home-Verzeichnisse einsehen. Die standen natürlich noch auf `/home`. Also haben wir einen Symlink von `/home` nach `/data/home` eingerichtet, was aber in manchen Anwendungen trotzdem Probleme brachte. Eigentlich hätte man alle Home-Verzeichnisse mittels `vipw` umschreiben müssen.

Gibt es sowas auch unter Linux?

Wenn du nach %ProgramFiles% suchst, dann nein.

Ich finde es auch nicht unbedingt praktikabel, einfach alle "Systemordner" als Umgebungsvariable zu exportieren. Wie gesagt wäre eine interne und systemweit gleiche Tabelle oder was Ähnliches praktisch, die über IDs oder eindeutige Schlüssel arbeitet. Um zu verdeutlichen was ich meine, brachte ich die Windows Directory-IDs ins Spiel.

Um beim Scripten etwas Distributions-unabhängiger zu werden, müsste schon auf jedem Linux oder besser sogar jedem Unix-artigem System eine Art Tabelle solcher Systemordner existieren. Gibt es so etwas?

Wieder ein klares jein, es gibt die LSB (Linux Standard Base), in der definiert ist, welche Ordner es geben muss, un das darin zu liegen hat, damit ein System LSB konform ist.

Aha, noch eine Information. Es gibt also "LSB konforme" Linux-Systeme? Wer vergibt diese Konformitäts-"Zertifikate" und gibt es eine Übersicht aller LSB-konformen Systeme?

Jede Distro kocht halt ihr eigenes Süppchen und nennt diese Pflichtordner entweder anders bzw. hält sie an einem anderen Ort. Dieses Wirrwarr sorgt für viele Probleme bei Software-Herstellern, so dass für jede Distro ein eigenes Paket geschnürt wird. Oder aber man kompiliert es sich selbst via Makefile. In diesem Makefile muss ja auch stehen, welche Dateien in welche Ordner wandern sollen. Woher bezieht `make` diese Informationen?

[armin]

Suchst du so etwas wie hier in 4.1: http://tldp.org/HOWTO/HighQuality-Apps-HOWTO/fhs.html ?
Home-Verzeichnisse haben in /home zu liegen, fertig - da brauch man dann nicht nochmal eine Umgebungsvariable die einem das gleiche sagt Selbiges gilt für andere Verzeichnisse, die in obigem Link genannt werden.

Wenn du es genauer wissen willst: http://www.pathname.com/fhs/

[goecke]

...
Ich möchte Skripte schreiben, die sich nicht auf einen statischen Befehl wie 'cp foo /home/droptix/foo' verlassen müssen. Vielmehr möchte ich das Home-Verzeichnis des Benutzers `droptix` irgendwo auslesen oder zumindest das allgemeine Home-Verzeichnis aller Benutzer auslesen. Würde man Umgebungsvariablen benutzen, hätte man sowas zur Verfügung: 'cp foo $HOME/droptix'. Wenn sich das globale Home-Verzeichnis mal ändert, funktioniert das Skript immernoch.

hier suchst du scheinbar

Code: Alles auswählen

cp foo ~droptix/foo

es ist so einfach möglich das $HOME einzelner Bentzer lokal auf dem Rechner zu halten,
das $HOME anderer Benutzer wiederum übers Netz zu mounten.

(wie auch i.A. /root das $HOME von Benutzer root ist und i.A. /home/user die "normalen Benutzer" )


alles ist relativ gut im FHS beschrieben.

kurz als Bslp:

/etc = globale config
/sbin = Admin Programme
/bin = Benutzer Programme (beide sollten lokal liegen, damit bei fehlerhaftem Netzwerk das System rudimentär administrierbar ist

/usr/sbin/
/usr/bin = wie oben nur für "Normalen" Betrieb (kann z.B. via NFS,... gemountet sein)

/var/ = sonstige Daten keine binaries je nach applikation (vgl fhs)
/tmp/ = Temporäre dateien (für alle User zusammen!)

nebenbei sollte man nicht irgendwelche anderen Dateien als in /home direkt ansprechen.
z.B. mail , squid-cache, Datenbanken würde ich ausschließlich über die Benutzerprogramme ansprechen.
(Ausnahme ggf. Backup)

als sehr allgemein formulierte Regel könnte gelten

/etc Darf der Admin editieren
/home/* die User

alles andere macht die Paketverwaltung
OK, es gibt viele Ausnahmen wie /var/www für Apache, aber es ist ein möglicher
Startpunkt

gruß
Johannes

[droptix]

Ja, das trifft es in etwa. Danke an euch!

1) Na ist es denn aber so, dass sich alle Linuxe daran halten, oder zumindest die LSB-konformen?

2) Fakt ist auch, dass man sich sein Linux bewusst anders strukturieren kann (s. mein Bsp. unten mit der zweiten Festplatte und `/data/home`). Kann man bei Fehlern die Schuld dann beim Admin suchen, der den Mist verbockt hat? Ich hatte bei unserem Fall schon damals dafür plädiert, lieber den Mountpoint von `/home` korrekt in der `/etc/fstab` umzuhängen als einen banalen Symlink zu erstellen… weil ich das instinktiv für sauberer hielt. Es hieß aber sinngemaß, das sei egal.

Bislang bin ich immer davon ausgegangen, dass das bei den verschiedenen Distros eben nicht alles so gleich ist. Das sieht man ja auch bei der Nutzerverwaltung oder wie bereits angeführt beim Apache-Verzeichnis.

[roli]

Hi,

Aha, da tasten wir uns schon näher ran. Dass jeder User eine Art Profil hat ist mir bekannt. Allerdings bin ich auch da nicht sooo bewandert. Also schmeiß ich mal eben meine Debian-Kiste an… In meinem Home-Verzeichnis liegt nur eine Datei namens `.bash_profile`. Diese Einstellungen gelten z.B. nur für die Bash, hat aber nichts mit Systemordnern zu tun. Im Home-Verzeichnis war's das dann eigentlich auch schon. Schauen wir mal nach `/etc`. Die liegen viele .conf-Dateien, aber jede für spezielle Anwendungen. Dann noch `environment` oder `fstab` (da kriegt man zumindest schonmal den Root-Mountpoint raus, was in der Windows-Welt %windir% entsprechen dürfte). In `profile` wird nur $PATH zu den Binaries angepasst. Mehr kann ich erstmal dort nicht finden.

du koenntest (je nach verwenderter Login-Shell, ...) in deinem User-Home, auch weitere Dateien finden, z.B. .bash_rc, .profile, ...

Ich möchte Skripte schreiben, die sich nicht auf einen statischen Befehl wie 'cp foo /home/droptix/foo' verlassen müssen. Vielmehr möchte ich das Home-Verzeichnis des Benutzers `droptix` irgendwo auslesen oder zumindest das allgemeine Home-Verzeichnis aller Benutzer auslesen. Würde man Umgebungsvariablen benutzen, hätte man sowas zur Verfügung: 'cp foo $HOME/droptix'. Wenn sich das globale Home-Verzeichnis mal ändert, funktioniert das Skript immernoch.

Das Homeverzeichnis des Users wird durch ~ "repraesentiert" (ich weiss nicht wie ich's anders ausdruecken soll). Z.B. du bist in /tmp, und moechtest zurueck in's Homeverzeichnis, dann bist du mit "cd ~" da. Mit "cd -" kommst du uebrigens wieder dahin zurueck wo du herkommst, hier also /tmp. Ich bin mir alerdings nicht sicher, ob das bei alles Shells so ist.

Ich finde es auch nicht unbedingt praktikabel, einfach alle "Systemordner" als Umgebungsvariable zu exportieren. Wie gesagt wäre eine interne und systemweit gleiche Tabelle oder was Ähnliches praktisch, die über IDs oder eindeutige Schlüssel arbeitet. Um zu verdeutlichen was ich meine, brachte ich die Windows Directory-IDs ins Spiel.

Da es "den" Systemordner bei Linux aber nicht gibt, was sollte da exportiert werden. Für mich waere /etc am ehesten der "Systemordner", aber da liegt kein "Systemtool", da liegen nur die Konfigurationsdateien.

Aha, noch eine Information. Es gibt also "LSB konforme" Linux-Systeme? Wer vergibt diese Konformitäts-"Zertifikate" und gibt es eine Übersicht aller LSB-konformen Systeme?

Joh, es gibt Distributionen die LSB Zertifiziert sind, und andere sind's nicht. Vergeben wird das Zertifikat von der Linux Foundation. Teil der LSB ist der FHS (Filesystem Hirarchie Standard), da ist definiert wo was zu liegen hat. Aber das hat Trigger. ja bereits geschrieben.

Jede Distro kocht halt ihr eigenes Süppchen und nennt diese Pflichtordner entweder anders bzw. hält sie an einem anderen Ort.

Richtig, aber sieh's mal so, jede Disti KANN ihre Daten ablegen wo sie will, MUSS es aber nicht. Auch das ist Freiheit, ob's wirklich clever ist wenn jeder was anders macht sei dahingestellt. Aber etwas nur zu machen weil es alle anderen auch so machen muss deshalb nicht besser sein.
Um mal das ganz grosse Rad zu drehen, es gibt mehrere Milliarden Menschen auf der Erde, waere es nicht einfacher alle wuerden die gleiche Sprache sprechen?

Dieses Wirrwarr sorgt für viele Probleme bei Software-Herstellern, so dass für jede Distro ein eigenes Paket geschnürt wird.

Bingo, oder eben nicht, weil sich die Hersteller die Muehe nicht machen. Um das ganze noch weiter zu verkomplizieren, gibt es dann noch die unterschiedlichsten Packetformate, deb, rpm, tgz, ...
Das ist sicher ein Grund der dazu gefuehrt hat, das der FHS und die LSB entstanden sind.

Oder aber man kompiliert es sich selbst via Makefile. In diesem Makefile muss ja auch stehen, welche Dateien in welche Ordner wandern sollen. Woher bezieht `make` diese Informationen?

Bei den Programmen die ich bisher uebersetzt habe, bestand zum einen nicht die Notwendigkeit etwas anzupassen, zum anderen hatten sie (alle) die Moeglichkeit das Installationsziel per Parameter zu übergeben.

<edit>Trigger. war's, nicht Tunix
Da ich heute Drathlos online bin, reisst off die Verbindung ab, daher kommt alles etwas "Zeitversetzt"</edit>

[Savar]

eigentlich sollte es auch mit dem Symlink funktionieren, aber dazu müsste man mal eine Beispiel Ausgabe eines Beispielskriptes (mit dessen Quellcode) sehen, bei dem was schiefgelaufen ist...

[droptix]

du koenntest (je nach verwenderter Login-Shell, ...) in deinem User-Home, auch weitere Dateien finden, z.B. .bash_rc, .profile, ...

Klar existieren die, aber das war nicht themenrelevant.

Das Homeverzeichnis des Users wird durch ~ "repraesentiert" (ich weiss nicht wie ich's anders ausdruecken soll). Z.B. du bist in /tmp, und moechtest zurueck in's Homeverzeichnis, dann bist du mit "cd ~" da.

Ja, das ist mir bekannt. Das ist aber ein Spezialfall für das eigene Homeverzeichnis und hat nichts direkt mit systemweiten Ordnern zu tun. Mit $HOME bin ich wohl etwas zu sehr am Home-Verzeichnis hängen geblieben… das war eher als anschauliches Beispiel zu verstehen.

Mit "cd -" kommst du uebrigens wieder dahin zurueck wo du herkommst, hier also /tmp. Ich bin mir alerdings nicht sicher, ob das bei alles Shells so ist.

Da hab ich was dazu gelernt! Bei der Bash geht's zumindest… Danke!

Da es "den" Systemordner bei Linux aber nicht gibt, was sollte da exportiert werden. Für mich waere /etc am ehesten der "Systemordner", aber da liegt kein "Systemtool", da liegen nur die Konfigurationsdateien.

Ich spreche ja auch nicht von "dem" Systemordner, sondern von allen. Es gibt ja (wie eurer Link oben zeigt) Ordner mit bestimmten Aufgaben. Wenn allerdings wirklich festgelegt ist, welcher Ordner wie zu heißen hat und wo der liegen muss, dann ist meine Anfrage schon geklärt.

Jede Distro kocht halt ihr eigenes Süppchen und nennt diese Pflichtordner entweder anders bzw. hält sie an einem anderen Ort.

Richtig, aber sieh's mal so, jede Disti KANN ihre Daten ablegen wo sie will, MUSS es aber nicht. Auch das ist Freiheit, ob's wirklich clever ist wenn jeder was anders macht sei dahingestellt. Aber etwas nur zu machen weil es alle anderen auch so machen muss deshalb nicht besser sein.
Um mal das ganz grosse Rad zu drehen, es gibt mehrere Milliarden Menschen auf der Erde, waere es nicht einfacher alle wuerden die gleiche Sprache sprechen?

Pauschal gesehen nicht "einfacher", aber prinzipiell liegst du schon richtig es würde sich vieles "vereinfachen", was wir heute als kompliziert empfinden. Damit geht aber auch viel verloren, wie z.B. Kultur. Stimmt schon, man kann das in einem gewissen Maße auch auf Systeme abbilden.

Dieses Wirrwarr sorgt für viele Probleme bei Software-Herstellern, so dass für jede Distro ein eigenes Paket geschnürt wird.

Bingo, oder eben nicht, weil sich die Hersteller die Muehe nicht machen. Um das ganze noch weiter zu verkomplizieren, gibt es dann noch die unterschiedlichsten Packetformate, deb, rpm, tgz, ...
Das ist sicher ein Grund der dazu gefuehrt hat, das der FHS und die LSB entstanden sind.

Da hatte wohl jemand vor mir schonmal diesen Wunsch nach Vereinheitlichung geäußert. Immerhin soll die Welt immer mehr zusammen wachsen, da sind ein paar Standards nunmal unvermeidlich, an die sich alle halten müssen. Im Straßenverkehr ist das ja auch so

eigentlich sollte es auch mit dem Symlink funktionieren, aber dazu müsste man mal eine Beispiel Ausgabe eines Beispielskriptes (mit dessen Quellcode) sehen, bei dem was schiefgelaufen ist...

Wenn ich mich recht erinnere, gab es ein Problem als `sudoer` und eben dem Home-Pfad. Da wurde $HOME nicht richtig aufgelöst. Vielleicht kann ich das mal eben gegenchecken…puh es ist etwas schwer nachzuvollziehen nach all der Zeit. Hier mal ein Auszug aus der Bash:

Code: Alles auswählen

user@hostname:~$ echo $HOME
/data/home/user
user@hostname:~$ su
Password:
hostname:/data/home/user# echo $HOME
/root
hostname:/data/home/user#

Bin mir nicht sicher, weil das eigentlich stimmt… Da müsste ich nochmal nachfragen, wo genau der Fehler war. Ich kann mich noch erinnern, dass unser Admin dann immer schnell die $HOME-Umgebungsvariable ändern musste.

[nepos]

Bei deiner letzten Frage ist entscheidend, ob du su oder sudo meinst.
sudo ändert nämlich per Default die Variable HOME nicht. Das heißt, wenn ich als User nepos was mit sudo aufrufe, dann bleibt HOME auf /home/nepos. In der Man-Page steht dazu auch noch mehr. Ebenfalls gibts es unter

Code: Alles auswählen

man sudoers

noch zwei Flags (set_home bzw. always_set_home), die das ebenfalls beeinflussen.

su dagegen setzt HOME auf den entsprechenden Wert des Users, zu dem du dich machst. Im Falle von root also /root/. Ausser, man ruft su mit den Optionen -m oder -p auf. Dann bleibt das Environment des Aufrufers von su erhalten.

[ToPeG]

Um das ganze zu strukturieren.

LSB konforme Linux-Dstributionen, halten sich an die Bestimmungen was Pfadanganen, vorhandenen Programme und deren Verhalten betrifft. Du kannst immer davon ausgehen, das du alles dort findest wo du es suchst.

Nicht LSB konforme Distributionen, kann man perse nicht gut unterstützen, denn selbst wenn es für so etwas alle möglichen Umgebungsvariablen gäbe, muß es nicht heißen, das sie vorhanden, oder korrekt sind, oder die Programme sich so Verhalten wie du erwatest, oder überhaupt vorhanden sind.

Links und auch symbolische Links verhalten sich Transparent. Es macht allso keinen Unterschied, ob "/home" selber ein Link ist oder direckt ein Verzeichnis. (so werden z.B. diese angelgt, wenn man unter Debian die LSB-konformität installiert.)

[nepos]

Wenn ich mich nicht irre gibt es auch unter Windows eigentlich recht klare Richtlinien von Microsoft, welche Daten wohin gespeichert werden sollten. Fällt mir nur grade mal so ein.
So etwas wie %WINDIR% brauchst du unter Linux z.B. auch nicht, weil das ja eh / ist und der Rest von dort aus zu finden ist.