Provided by: manpages-de-dev_2.5-1_all bug

BEZEICHNUNG

       execve - Programm ausführen

ÜBERSICHT

       #include <unistd.h>

       int execve(const char *filename, char *const argv[],
        char *const envp[]);

BESCHREIBUNG

       execve()  führt  das  Programm  aus,  auf  das  filename  verweist.  filename  muss  entweder ein binäres
       ausführbares Programm oder ein Skript sein, das mit einer Zeile der folgenden Form beginnt:

           #! Interpreter [Optionale-Arg]

       Einzelheiten zu letzterem Fall finden Sie in »Interpreter-Skripte« weiter unten.

       argv ist ein Feld von Argumentezeichenketten, die an das neue Programm übergeben werden.  Per  Konvention
       sollte  die  erste  dieser  Zeichenketten  (d.h.  argv[0]) den Dateinnamen, der zu der ausgeführten Datei
       gehört, enthalten. envp ist ein Feld von Zeichenketten, das per Konvention die Form Schlüssel=Wert  haben
       sollte,  das  an  die  Umgebung des neuen Programms übergeben wird. Die Felder argv und envp müssen jeder
       einen Null-Zeiger am Ende des Feldes enthalten.

       Auf den Argumentzeiger und die Umgebung kann von der Main-Funktion des aufgerufenen Programms zugegriffen
       werden, wenn sie wie folgt definiert ist:

           int main(int argc, char *argv[], char *envp[])

       Beachten Sie allerdings, dass die Verwendung eines dritten Arguments  bei  der  Funktion  main  nicht  in
       POSIX.1  spezifiziert  ist;  laut  POSIX.1  sollte  auf die Umgebung über die externe Variable environ(7)
       zugegriffen werden.

       execve() kehrt bei Erfolg nicht zurück und Text, initialisierte Daten, uninitalisierte  Daten  (bss)  und
       Stack   des   aufrufenden   Prozesses  werden  entsprechend  des  Inhalts  des  neu  geladenen  Programms
       überschrieben.

       Falls das aktuelle Programm mit ptrace verfolgt wird, wird nach einem erfolgreichen execve()  ein  Signal
       SIGTRAP an es gesandt.

       Falls  bei  der  Programmdatei,  auf  die  filename zeigt, das Bit set-user-ID gesetzt ist, dann wird die
       effektive Benutzerkennung des aufrufenden Programms zu der des Eigentümers  der  Programmdatei  geändert.
       Ähnlich wird die effektive Gruppen-ID des aufrufenden Prozesses auf die Gruppe der Programmdatei gesetzt,
       wenn das Bit »set-group-ID« auf der Programmdatei gesetzt ist.

       Die vorgenannten Umwandlungen der effektiven IDs werden nicht durchgeführt (d.h. die Bits set-user-ID und
       set-group-ID werden ignoriert), falls eine der folgenden Aussagen wahr ist:

       *  Das Attribut no_new_privs wird für den aufrufenden Thread gesetzt (siehe prctl(2)).

       *  Das unterliegende Dateisystem ist nosuid eingehängt (der Schalter MS_NOSUID für mount(2)). Oder

       *  der aufrufende Prozess wird mit ptrace verfolgt.

       Die  Capabilities  der  Programmdatei (siehe capabilities(7)) werden auch ignoriert, wenn eine der obigen
       Bedingungen zutrifft.

       Die effektive Benutzerkennung des Prozesses wird in die gespeicherte set-user-ID  kopiert.  Ähnlich  wird
       die  effektive  Gruppen-ID  in  die  gespeicherte set-group-ID kopiert. Dieses Kopieren findet nach allen
       effektiven ID-Änderungen statt, die aufgrund der Modusbits set-user-ID und set-group-ID erfolgen.

       Die echte UID und echte GID des Prozesses sowie die zusätzlichen Gruppen-IDs ändern sich beim Aufruf  von
       execve() nicht.

       Falls    das    Programm    eine    dynamisch   gelinkte   Programmdatei   im   a.out-Format   ist,   die
       Laufzeitbibliotheken-Stubs enthält, dann wird der dynamische Linker ld.so(8)  von  Linux  am  Anfang  der
       Ausführung  aufgerufen, um die benötigten Laufzeitobjekte in den Speicher zu bringen und das Programm mit
       ihnen zu verlinken.

       Falls das Programm ein dynamisch gelinktes ELF-Programm ist, wird der in dem Segment  PT_INTERP  benannte
       Interpreter   zum   Laden  der  gemeinsamen  Objekte  verwandt.  Dieser  Interpreter  ist  typischerweise
       /lib/ld-linux.so.2 für Programme, die mit der Glibc gelinkt sind (siehe ld-linux.so(8)).

       Alle außer den nachfolgend aufgeführten Prozessattributen werden durch ein execve() erhalten:

       *  Die Zuordnung aller gefangen Signale wird auf die Vorgabe zurückgesetzt (signal(7)).

       *  Alle alternativen Signal-Stacks werden nicht erhalten (sigaltstack(2)).

       *  Memory mappings are not preserved (mmap(2)).

       *  Gemeinsam benutzte Speichersegmente vom Typ »System V« werden abgetrennt (shmat(2)).

       *  POSIX shared memory regions are unmapped (shm_open(3)).

       *  Offene POSIX-Nachrichtenwarteschlangendeskriptoren werden geschlossen (mq_overview(7)).

       *  Alle offenen benannten POSIX-Semaphoren werden geschlossen (sem_overview(7)).

       *  POSIX-Zeitgeber werden nicht erhalten (timer_create(2)).

       *  Alle offenen Verzeichnis-Streams werden geschlossen (opendir(3)).

       *  Speichersperren werden nicht erhalten (mlock(2), mlockall(2)).

       *  Exit-Handler werden nicht erhalten (atexit(3), on_exit(3)).

       *  Die Gleitkomma-Umgebung wird auf den Standardwert zurückgesetzt (siehe fenv(3)).

       Die Prozessattribute in  der  vorstehenden  Liste  sind  alle  in  POSIX.1  spezifiziert.  Die  folgenden
       Linux-spezifischen Prozessattribute werden auch während eines execve() nicht erhalten:

       *  Der  prctl(2)-Schalter  PR_SET_DUMPABLE wird gesetzt. Wird ein set-user-ID- oder set-group-ID-Programm
          ausgeführt, dann wird er auf 0 gesetzt.

       *  Der prctl(2)-Schalter PR_SET_KEEPCAPS wird auf 0 gesetzt.

       *  (Seit Linux 2.4.36 / 2.6.23) Falls ein set-user-ID- oder set-group-ID-Programm ausgeführt  wird,  dann
          wird  das  durch den Schalter prctl(2) PR_SET_PDEATHSIG gesetzte Todessignal des Elternprozesses auf 0
          gesetzt.

       *  Der Prozessname, wie er von prctl(2) PR_SET_NAME gesetzt (und durch ps -o comm angezeigt)  wird,  wird
          auf den Namen des ausführbaren Programms zurückgesetzt.

       *  Der SECBIT_KEEP_CAPS Schalter securebits wird auf 0 gesetzt. Siehe capabilities(7).

       *  Das Terminierungssignal wird auf SIGCHLD zurückgesetzt (siehe clone(2)).

       *  Die  Dateideskriptortabelle  wird  getrennt,  der  Effekt  des Schalters CLONE_FILES von clone(2) wird
          rückgängig gemacht.

       Beachten Sie die folgenden weiteren Punkte:

       *  Alle Threads außer dem aufrufenden werden während eines execve() zerstört. Mutexe, Bedingungsvariablen
          und andere Pthread-Objekte werden nicht erhalten.

       *  Das Äquivalent von setlocale(LC_ALL, "C") wird beim Programmstart ausgeführt.

       *  POSIX.1 legt fest, dass Zuordnungen aller ignorierten oder  auf  die  Vorgabewerte  gesetzten  Signale
          unverändert  bleiben.  POSIX.1  legt  eine Ausnahme fest: Falls SIGCHLD ignoriert wird, dann darf eine
          Implementierung die Zuordnung unverändert lassen oder sie auf die Vorgabe  zurücksetzen;  Linux  macht
          ersteres.

       *  Alle ausstehenden asynchronen E/A-Operationen werden abgebrochen (aio_read(3), aio_write(3)).

       *  Für den Umgang mit Capabilities während execve(), siehe capabilities(7).

       *  Standardmäßig  bleiben  Dateideskriptoren  über  ein execve() hinweg offen. Dateideskriptoren, die mit
          close-on-exec markiert sind, werden geschlossen; siehe die Beschreibung von  FD_CLOEXEC  in  fcntl(2).
          (Falls  ein  Dateideskriptor  geschlossen  wird,  führt dies zur Freigabe aller von der unterliegenden
          Datei durch den Prozess erhaltenen Datensatzsperren. Siehe fcntl(2) für Details.)  Laut  POSIX.1  darf
          das System eine nicht festgelegte Datei für jeden der Dateideskriptoren 0, 1 und 2 öffnen, falls diese
          andernfalls  nach  einem  erfolgreichen  execve()  geschlossen und der Prozess aufgrund der Modus-Bits
          set-user-ID oder set-group_ID Privilegien erhalten würde. Als allgemeines Prinzip darf kein  portables
          Programm,  egal  ob  privilegiert  oder  nicht,  annehmen,  dass diese drei Dateideskriptoren über ein
          execve() geschlossen bleiben.

   Interpreter-Skripte
       Ein Interpreter-Skript ist eine Textdatei, die über Ausführrechte verfügt  und  dessen  erste  Zeile  die
       folgende Form annimmt:

           #! Interpreter [Optionale-Arg]

       Der  interpreter  muss ein gültiger Pfadname für eine ausführbare Datei sein. Falls das Argument filename
       von execve()  ein  Interpreterskript  festlegt,  dann  wird  interpreter  mit  den  folgenden  Argumenten
       aufgerufen.

           Interpreter [Optionale-Arg] filename Arg …

       wobei Arg… eine Reihe von Wörtern ist, auf die vom Arugment argv von execve() gezeigt wird, beginnend bei
       argv[1].

       Für  den  portablen  Einsatz  sollte  Optionale-Arg  entweder abwesend oder als einzelnes Wort festgelegt
       werden (d.h. es sollte keine Leerraumzeichen enthalten); siehe ANMERKUNGEN unten.

       Seit Linux 2.6.28 erlaubt es der Kernel, dass der Interpreter eines Skripts selbst wieder ein Skript ist.
       Diese Erlaubnis ist rekursiv bis zu einer Rekursionstiefe von 4, so dass der Interpreter ein Skript  sein
       darf, das von einem Skript interpretiert wird und so weiter.

   Begrenzungen der Größe der Argumente und der Umgebung
       Die  meisten  UNIX-Implementierungen  verhängen eine Begrenzung für die Gesamtgröße der Zeichenketten der
       Befehlszeilenargumente (argv) und der Umgebung (envp), die an ein neues Programm übergeben  werden  darf.
       POSIX.1  erlaubt  es  einer  Implementierung,  diese  Begrenzung mit der Konstante ARG_MAX bekanntzugeben
       (entweder definiert in <limits.h> oder zur Laufzeit mit dem Aufruf sysconf(_SC_ARG_MAX) verfügbar).

       Vor Kernel 2.6.23 unter Linux war der Speicher, der zum Ablegen der Umgebungs- und  Argumentzeichenketten
       verwandt  wurde,  auf  32  Seiten  begrenzt  (definiert  durch  die  Kernelkonstante  MAX_ARG_PAGES). Auf
       Architekturen mit einer 4-kB-Seitengröße führt dies zu einer Maximalgröße von 128 kB.

       Auf den meisten Architekturen wird unter Kernel 2.6.23 und  neuer  eine  Größenbegrenzung,  die  von  der
       Ressourcenbegrenzung  RLIMIT_STACK  (siehe  getrlimit(2))  abgeleitet  ist, die zum Zeitpunkt des Aufrufs
       execve() in Kraft war, unterstützt. (Architekturen ohne Speicherverwaltungseinheit sind die Ausnahme: bei
       Ihnen bleibt die Begrenzung, die vor  dem  Kernel  2.6.23  in  Kraft  war.)  Diese  Änderung  erlaubt  es
       Programmen,  eine  viel größere Argumenten- und/oder Umgebungsliste zu haben. Für diese Architekturen ist
       die Gesamtgröße auf 1/4 der erlaubten Stack-Größe begrenzt. (Die  Erzwingung  der  1/4-Begrenzung  stellt
       sicher,  dass neue Programme immer über Stack-Bereich verfügen.) Seit Linux 2.6.25 stellt der Kernel eine
       Untergrenze von 32 Seiten dieser Begrenzung bereit, so dass selbst wenn  RLIMIT_STACK  sehr  gering  ist,
       Anwendungen garantiert über mindestestens so viel Argument- und Umgebungsbereich verfügen, wie dies unter
       Linux  2.6.23 und älter der Fall war. (Diese Garantie wurde nicht unter Linux 2.6.23 und 2.6.24 erfüllt.)
       Zusätzlich ist die Begrenzung pro Zeichenkette 32 Seiten (der Kernelkonstanten  MAX_ARG_STRLEN)  und  die
       maximale Anzahl von Zeichenketten ist 0x7FFFFFFF.

RÜCKGABEWERT

       Im  Erfolgsfall kehrt execve() nicht zurück, im Fehlerfall wird -1 zurückgeliefert und errno entsprechend
       gesetzt.

FEHLER

       E2BIG  Die Gesamtanzahl von Bytes in der Umgebungs- (envp) und der Argumentenliste (argv) ist zu groß.

       EACCES Für einen Teil des Pfadpräfixes von filename oder  dem  Namen  des  Skript-Interpreters  wird  die
              Suchberechtigung verweigert. (Siehe auch path_resolution(7).)

       EACCES Die Datei oder der Skriptinterpreter ist keine reguläre Datei.

       EACCES Für die Datei oder ein Skript oder ELF-Interpreter wird die Ausführberechtigung verweigert.

       EACCES Das Dateisystem ist nicht noexec eingehängt.

       EAGAIN (seit Linux 3.1)
              Nach  Änderung  der  echten UID mittels einer der Aufrufe set*uid() war – und ist immer noch – der
              Aufrufende  über  seine  Ressourcenbegrenzung  RLIMIT_NPROC   (siehe   setrlimit(2)).   Für   eine
              detailliertere Erläuterung dieses Fehlers siehe ANMERKUNGEN.

       EFAULT filename  oder  einer der Zeiger in den Vektoren argv oder envp zeigt aus dem für Sie zugänglichen
              Adressraum heraus.

       EINVAL Ein ELF-Programm hat mehr als ein PT_INTERP-Segment (d.h. versuchte  mehr  als  einen  Interpreter
              anzugeben).

       EIO    Es ist ein E/A-Fehler (engl. I/O) aufgetreten.

       EISDIR Ein ELF-Interpreter war ein Verzeichnis.

       ELIBBAD
              Ein ELF-Interpreter war in einem unbekannten Format.

       ELOOP  Beim  Auflösen  von  filename  oder  dem Namen eines Skripts oder ELF-Interpreters wurden zu viele
              symbolische Links ermittelt.

       ELOOP  Während der rekursiven Skript-Interpretation (siehe »Interpreter-Skripte« oben) wurde die maximale
              Rekursionsbegrenzung erreicht. Vor Linux 3.8 wurde in diesem Fall der Fehler ENOEXEC erstellt.

       EMFILE Die Beschränkung pro Prozess der Anzahl offener Datei-Deskriptoren wurde erreicht.

       ENAMETOOLONG
              filename ist zu lang.

       ENFILE Die systemweite Beschränkung für die Gesamtzahl offener Dateien wurde erreicht.

       ENOENT Die  Datei  filename  oder  ein  Skript  oder  ein  ELF-Interpreter  existiert  nicht  oder   eine
              Laufzeitbibliothek,  die  für  die  Datei  oder den Interpreter benötigt wird, kann nicht gefunden
              werden.

       ENOEXEC
              Ein Programm ist nicht in einem erkennbaren Format, ist für die falsche Architektur oder hat einen
              anderen Formatfehler, wodurch es nicht ausgeführt werden kann.

       ENOMEM Es war nicht genügend Kernelspeicher verfügbar.

       ENOTDIR
              Ein Teil des Pfadpräfixes von filename oder ein Skript oder ELF-Interpreter ist kein Verzeichnis.

       EPERM  Das Dateisystem ist nosuid eingehängt, der Benutzer ist nicht der Superuser und die Datei hat  das
              Bit set-user-ID oder set-group-ID gesetzt.

       EPERM  Der  Prozess  wird  verfolgt,  der  Benutzer  ist  nicht  der  Superuser und die Datei hat das Bit
              set-user-ID oder set-group-ID gesetzt.

       EPERM  Eine »Capability-unfähige« Anwendung würde nicht die ganze Menge  der  vom  ausführbaren  Programm
              gewährten erlaubten Capabilities erhalten. Siehe capabilities(7).

       ETXTBSY
              Das angegebene Programm war für einen oder mehrere Prozesse zum Schreiben offen.

KONFORM ZU

       POSIX.1-2001,  POSIX.1-2008,  SVr4,  4.3BSD. POSIX dokumentiert das #!-Verhalten nicht, es existiert aber
       (mit einigen Variationen) auf anderen UNIX-Systemen.

ANMERKUNGEN

       Set-user-ID- und Set-group-ID-Prozesse können nicht mit ptrace(2) verfolgt werden.

       Das  Ergebnis  des  Einhängens  eines  Dateisystems  mit  nosuid  unterscheidet  sich  abhängig  von  der
       Linux-Kernelversion.  Unter  einigen  wird die Ausführung von Programmen mit set-user-ID und set-group-ID
       verweigert,  wenn  das  dem  Benutzer  Rechte  geben  würde,  die  er  nicht  bereits  hatte  (und  EPERM
       zurückliefern).  Unter  anderen  werden  die  Bits  set-user-ID  und  set-group-ID  ignoriert  und exec()
       erfolgreich ausgeführt.

       Unter Linux können argv und envp als NULL festgelegt werden. In  beiden  Fällen  hat  dies  den  gleichen
       Effekt  wie  die  Festlegung  des Arguments auf einen Zeiger auf eine Liste, die als einziges Element den
       NULL-Zeiger enthält. Nutzen Sie diese nicht standardisierte und nicht  portable  Misfunktionalität  nicht
       aus!  Unter  vielen UNIX-Systemen führt die Festlegung von argv als NULL zu einem Fehler (EFAULT). Einige
       andere UNIX-Systeme behandeln den Fall envp==NULL wie Linux.

       POSIX.1 besagt, dass die von sysconf(3) zurückgelieferten Werte  über  die  Lebensdauer  eines  Prozesses
       unveränderlich  sein  sollen.  Seit  2.6.23 wird der von _SC_ARG_MAX berichtete Wert sich allerdings auch
       ändern, wenn die Ressourcenbegrenzung RLIMIT_STACK sich ändert, um die Tatsache zu berücksichtigen,  dass
       die Begrenzung des Platzes zum Halten der Befehlszeilenargumente und der Umgebungsvariablen sich geändert
       hat.

       In  den  meisten  Fällen, in denen execve() fehlschlägt, kehrt die Steuerung zu dem ursprünglichen Abbild
       zurück und der  Aufrufende  von  execve()  kann  mit  dem  Fehler  umgehen.  In  (seltenen)  Fällen  kann
       (typischerweise durch Ressourcenerschöpfung verursacht) der Fehlschlag den Punkt ohne Rückkehr passieren:
       das ursprüngliche Abbild wurde bereits entfernt aber das neue Abbild konnte nicht komplett gebaut werden.
       In diesen Fällen beendet der Kernel den Prozess mit einem Signal SIGKILL.

   Interpreter-Skripte
       Eine  maximale  Zeilenlänge  von  127  Zeichen  wird  für die erste Zeile in einem interpretierten Skript
       erlaubt.

       Die  Semantik  des  Arguments  Optionale-Args  eines  Interpreterskriptes  unterscheidet  sich   zwischen
       Implementierungen.  Unter  Linux  wird  die  gesamte  Zeichenkette,  die  Interpreter folgt, als einziges
       Argument an den Interpreter übergeben und diese Zeichenkette kann Leerzeichen  enthalten.  Das  Verhalten
       unterscheidet  sich aber auf einigen anderen Systemen. Einige Systeme verwenden das erste Leerzeichen, um
       Optionale-Args zu beenden. Auf einigen Systemen kann ein Interpreterskript mehrere  Argumente  haben  und
       Leerzeichen in Optionale-Args werden zum Begrenzen der Argumente verwandt.

       Linux ignoriert die Bits set-user-ID und set-group-ID bei Skripten.

   execve() und EAGAIN
       Eine  detailliertere  Beschreibung  des  Fehlers  EAGAIN,  der  (seit Linux 3.1) beim Aufruf von execve()
       auftreten kann, ist wie folgt:

       Der Fehler EAGAIN kann  auftreten,  wenn  ein  vorhergehender  Aufruf  von  setuid(2),  setreuid(2)  oder
       setresuid(2)  dazu führte, dass die echte Benutzerkennung des Prozesses geändert wurde und diese Änderung
       dazu führte, dass der Prozess seine Ressourcenbeschränkung RLIMIT_NPROC überschritt (d.h. die Anzahl  der
       zu  der  neuen  echten UID gehörenden Prozesse überschreitet die Ressourcenbeschränkung). Von Linux 2.6.0
       bis 3.0 führte dies dazu, dass der Aufruf set*uid() fehlschlug. (Vor 2.6 wurde die Ressourcenbeschränkung
       bei Prozessen, die ihre Benutzerkennungs änderten, nicht durchgesetzt.)

       Seit Linux 3.1 schlägt in dem gerade beschriebenen Szenario der Aufruf set*uid() nicht mehr fehl, da dies
       zu oft zu Sicherheitslöchern führte, bei denen fehlerhafte Anwendungen nicht den Rückgabewert prüften und
       annahmen, dass – falls der Aufrufende Root-Rechte hatte  –  der  Aufruf  immer  erfolgreich  sein  würde.
       Stattdessen  ändert  der  Aufruf  set*uid()  jetzt erfolgreich die echte UID, aber der Kernel setzt einen
       internen Schalter namens PF_NPROC_EXCEEDED, um zu vermerken, dass die Ressourcenbeschränkung RLIMIT_NPROC
       überschritten wurde. Falls der Schalter PF_NPROC_EXCEEDED gesetzt ist und die Ressourcenbeschränkung  zum
       Zeitpunkt  eines  folgenden execve()-Aufrufs immer noch überschritten ist, dann schlägt dieser Aufruf mit
       dem Fehler EAGAIN fehl. Diese Kernellogik stellt sicher, dass die Ressourcenbeschränkung RLIMIT_NPROC für
       den häufigen Ablauf bei privilegierten Daemons  –  also  fork(2)  +  set*uid()  +  execve()  –  weiterhin
       durchgesetzt wird.

       Falls  die  Ressourcenbegrenzung  zum  Zeitpunkt  des Aufrufs execve() noch nicht überschritten wurde (da
       andere zu dieser echten UID gehörende Prozesse sich zwischen dem Aufruf von set*uid() und dem Aufruf  von
       execve()   beendeten)   dann   gelingt   der   Aufruf   und  der  Kernel  bereinigt  den  Prozessschalter
       PF_NPROC_EXCEEDED. Der Schalter wird auch auf 0 gesetzt, falls ein folgender  Aufruf  von  fork(2)  durch
       diesen Prozess gelingt.

   Geschichtliches
       Unter   UNIX V6  wurde  die  Argumentenliste  von  einem  exec()-Aufruf  durch  0  beendet,  während  die
       Argumentenliste von main durch -1 beendet wurde.  Daher  war  diese  Argumentenliste  nicht  für  weitere
       exec()-Aufrufe direkt verwendbar. Seit UNIX V7 sind beide NULL.

BEISPIEL

       Das folgende Programm ist dafür gedacht, vom zweiten folgenden Programm ausgeführt zu werden. Es gibt nur
       seine Befehlszeile (eine pro Zeile) wieder aus.

           /* myecho.c */

           #include <stdio.h>
           #include <stdlib.h>

           int
           main(int argc, char *argv[])
           {
               int j;

               for (j = 0; j < argc; j++)
                   printf("argv[%d]: %s\n", j, argv[j]);

               exit(EXIT_SUCCESS);
           }

       Dieses  Programm  kann  zur  Ausführung  des in seinem Befehlszeilenargument benannten Programms verwandt
       werden:

           /* execve.c */

           #include <stdio.h>
           #include <stdlib.h>
           #include <unistd.h>

           int
           main(int argc, char *argv[])
           {
               char *newargv[] = { NULL, "Hallo", "Welt", NULL };
               char *newenviron[] = { NULL };

               if (argc != 2) {
                printf(stderr, "Aufruf: %s <auszuführende-Datei>\n", argv[0]);
                exit(EXIT_FAILURE);
               }

               newargv[0] = argv[1];

               execve(argv[1], newargv, newenviron);
               perror("execve");   /* execve() kehrt nur im Fehlerfall zurück */
               exit(EXIT_FAILURE);
           }

       Wir können das zweite Programm verwenden, um das erste wie folgt aufzurufen:

           $ cc myecho.c -o myecho
           $ cc execve.c -o execve
           $ ./execve ./myecho
           argv[0]: ./myecho
           argv[1]: Hallo
           argv[2]: Welt

       Wir können diese Programme auch zur Demonstration der  Verwendung  eines  Skript-Interpreters  verwenden.
       Dafür erstellen wir ein Skript, dessen »Interpreter« unser myecho-Programm ist.

           $ cat > script
           #!./myecho script-arg
           ^D
           $ chmod +x script

       Wir können dann unser Programm verwenden, um das Skript auszuführen:

           $ ./execve ./script
           argv[0]: ./myecho
           argv[1]: script-arg
           argv[2]: ./script
           argv[3]: Hallo
           argv[4]: Welt

SIEHE AUCH

       chmod(2),   execveat(2),   fork(2),   get_robust_list(2),  ptrace(2),  execl(3),  fexecve(3),  getopt(3),
       system(3), credentials(7), environ(7), path_resolution(7), ld.so(8)

KOLOPHON

       Diese Seite ist Teil der Veröffentlichung  4.15  des  Projekts  Linux-man-pages.  Eine  Beschreibung  des
       Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden
       sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese  Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer
       bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

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

Linux                                          15. September 2017                                      EXECVE(2)