Provided by: manpages-de-dev_0.10-1_all bug

BEZEICHNUNG
       realpath - gibt den standardisierten absoluten Pfadnamen zuruck


"UBERSICHT
       #include <limits.h>
       #include <stdlib.h>

       char *realpath(const char *pfad, char *aufgeloester_pfad);

   Mit Glibc erforderliche Makros (siehe feature_test_macros(7)):

       realpath():
           _BSD_SOURCE || _XOPEN_SOURCE >= 500 ||
           _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED


BESCHREIBUNG
       realpath expandiert alle symbolischen Links  und  lost  Referenzen  auf
       >>.<<,   >>..<<  und  zusatzlichen  >>/<<-Zeichen  in  der  durch  Null
       beendeten Zeichenkette pfad auf, um  einen  standardisierten  absoluten
       Pfadnamen   zu   erzeugen.   Der   resultierende   Pfadname   wird  als
       Zeichenkette, die durch Null beendet wird, in dem  Puffer  mit  maximal
       PATH_MAX   Byte  gespeichert,  auf  den  aufgeloester_pfad  zeigt.  Der
       resultierende Pfad enthalt  weder  einen  symbolischen  Link  noch  die
       Komponenten >>.<< und >>..<<.

       Falls  aufgeloester_pfad  als  NULL angegeben wurde, benutzt realpath()
       malloc(3), um den Puffer des aufgelosten Pfadnamens von  PATH_MAX  Byte
       zu  reservieren  und  gibt  einen  Zeiger auf diesen Puffer zuruck. Der
       Aufrufende sollte den reservierten Speicher dieses Puffers mit  free(3)
       freigeben.


R"UCKGABEWERT
       Wenn   kein   Fehler   auftritt,   gibt  realpath()  einen  Zeiger  auf
       aufgeloester_pfad zuruck.

       Anderenfalls wird ein NULL-Zeiger zuruckgegeben, der Inhalt des  Feldes
       aufgeloester_pfad  ist unbestimmt und errno wird gesetzt. um den Fehler
       anzuzeigen.


FEHLER
       EACCES Der Lese- oder Suchzugriff fur eine Komponente des Pfad-Prafixes
              wurde verweigert.

       EINVAL Entweder  ist  pfad oder aufgeloester_pfad NULL. (In Libc5 wurde
              dies nur eine Schutzverletzung verursachen.) Aber lesen Sie  die
              folgenden ANMERKUNGEN.

       EIO    Wahrend des Lesens aus dem Dateisystem trat ein E/A-Fehler auf.

       ELOOP  Wahrend   der   Umwandlung   des   Pfadnamens  traten  zu  viele
              symbolische Links auf.

       ENAMETOOLONG
              Eine Komponente eines Pfadnameds uberschreitet NAME_MAX  Zeichen
              oder ein ganzer Pfadname uberschreitet NAME_MAX Zeichen.

       ENOENT Die genannte Datei existiert nicht.

       ENOTDIR
              Eine Komponente des Pfad-Prafixes ist kein Verzeichnis.


VERSIONEN
       Auf Linux erschien diese Funktion in Libc 4.5.21.


KONFORM ZU
       4.4BSD, POSIX.1-2001.

       Laut  POSIX.1-2001  ist das Verhalten, wenn aufgeloester_pfad NULL ist,
       abhangig  von  der  Implementierung.  POSIX.1-2008   spezifiziert   das
       Verhalten, das auf dieser Seite beschrieben wird.


ANMERKUNGEN
       Auf  4.4BSD  und  Solaris  ist  die  Langenbeschrankung  des Pfadnamens
       MAXPATHLEN (in <sys/param.h>). SUSv2 schreibt vor,  dass  PATH_MAX  und
       NAME_MAX  in  <limits.h>  stehen  oder  von  der  Funktion  pathconf(3)
       bereitgestellt werden. Ein typischer  Quellcode-Ausschnitt  konnte  wie
       folgt aussehen

           #ifdef PATH_MAX
             path_max = PATH_MAX;
           #else
             path_max = pathconf(path, _PC_PATH_MAX);
             if (path_max <= 0)
               path_max = 4096;
           #endif

       (Aber lesen Sie den Abschnitt FEHLER.)

       Die  4.4BSD-,  Linux-  and  SUSv2-Versionen geben immer einen absoluten
       Pfadnamen zuruck. Solaris kann einen relativen  Pfadnamen  zuruckgeben,
       wenn das Argument pfad relativ ist. Der Prototyp von realpath() wird in
       <unistd.h>  in  Libc4  und  Libc5  angegeben,  aber  sonst  uberall  in
       <stdlib.h>.


FEHLER
       Die  POSIX.1-2001-Standardversion dieser Funktion ist durch ihre Bauart
       kaputt, da es unmoglich ist  eine  passende  GroBe  des  Ausgabepuffers
       aufgeloester_pfad  zu  bestimmen.  GemaB POSIX.1-2001 reicht ein Puffer
       der GroBe PATH_MAX aus, aber PATH_MAX muss keine  definierte  Konstante
       sein und konnte durch die Benutzung von pathconf(3) erlangt werden. Die
       Abfrage von pathconf(3)  hilft  nicht  wirklich,  da  POSIX  einerseits
       warnt,   dass  das  Ergebnis  groB  und  fur  die  Speicherreservierung
       ungeeignet  sein  konnte  und  andererseits   konnte   pathconf(3)   -1
       zuruckgeben,  um  zu  kennzeichnen,  dass  PATH_MAX unbegrenzt ist. Die
       Eigenschaft aufgeloester_pfad == NULL die nicht in POSIX.1-2001, jedoch
       in POSIX.1-2008 standardisiert ist, ermoglicht es, dieses Bauartproblem
       zu vermeiden.

       Die   Implementierungen   von   Libc4   und   Libc5   enthalten   einen
       Pufferuberlauf    (behoben    in    Llibc-5.4.13).    Daher   benotigen
       SUID-Programme, wie mount(8), eine private Version.


SIEHE AUCH
       readlink(2),   canonicalize_file_name(3),    getcwd(3),    pathconf(3),
       sysconf(3)


KOLOPHON
       Diese   Seite   ist   Teil   der  Veroffentlichung  3.32  des  Projekts
       Linux-man-pages. Eine Beschreibung des Projekts und Informationen,  wie
       Fehler     gemeldet     werden     konnen,     finden     sich    unter
       http://www.kernel.org/doc/man-pages/.


"UBERSETZUNG
       Die deutsche Ubersetzung dieser Handbuchseite wurde von Patrick  Rother
       <krd@gulu.net> und Chris Leick <c.leick@vollbio.de> erstellt.

       Diese  Ubersetzung  ist  Freie Dokumentation; lesen Sie die GNU General
       Public  License  Version  3  oder  neuer   bezuglich   der   Copyright-
       Bedingungen. Es wird KEINE HAFTUNG ubernommen.

       Wenn  Sie  Fehler  in  der  Ubersetzung  dieser  Handbuchseite  finden,
       schicken     Sie     bitte     eine     E-Mail     an     <debian-l10n-
       german@lists.debian.org>.

                              20. September 2010                   REALPATH(3)