Comment fermer stdout et stderr en C?

Vous pouvez juste:

fclose(stdout);
fclose(stderr);

Pour quelqu'un de vous demander pourquoi vous pourriez vouloir faire cela, c'est une tâche courante pour un démon/service de processus sous Unix.

Cependant vous devez être conscient que la fermeture d'un descripteur de fichier peut avoir des conséquences inattendues:

• Lorsque vous ouvrez de nouveaux fichiers maintenant ces descripteurs libres seront utilisés. Ainsi, par exemple, si vous avez par la suite fopen ce descripteur de fichier (sur Linux, au moins) remplacera fd 1, c'est à dire la sortie standard stdout. Tout code qui utilise ensuite ce sera d'écrire dans ce fichier, qui peut ne pas être ce que vous souhaitiez.
• Voir R..'s commentaires sur les descripteurs de fichier par rapport à C bibliothèque FILE* pointeurs. Plus précisément:
  • Si vous écrivez à un fermé fd sous Linux, vous obtiendrez une erreur, mais:
  • Si vous utilisez une fonction de la bibliothèque C qui utilise stdout ou stderr (qui sont FILE* pointeurs (voir leur définition) alors l'écriture de ces tandis que FILE* est fermé est un comportement indéterminé. Ce sera probablement le plantage de votre programme, de façon inattendue, pas toujours au point du bug. Voir comportement indéfini.
• Votre code n'est pas la seule partie affectée. Toutes les bibliothèques que vous utilisez, et de tout processus de lancement qui a hérité de ces descripteurs de fichiers que leurs descripteurs standards sont également touchés.

Rapide, une solution en ligne est de freopen() - À-dire /dev/null/dev/console sous Linux/OSX ou nul sur Windows. Alternativement, vous pouvez utiliser votre plate-forme de mise en œuvre de ré-ouvrir les descripteurs de fichier/poignées en tant que de besoin.

Avertissement: je ne suis pas expérimenté en C, mais récemment lu une diapositive qui répond à cette question directement par Jim Meyering, une RedHat employé et GNUlib responsable: https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf. Je me contenterai de résumer.

TL;DR

Obtenir closeout.c et ses dépendances de GNUlib dans votre source, et de les appeler

atexit(close_stdout);

comme première ligne dans la principale.

Sommaire

Tout d'abord, certains chefs d'avertissement, citant POSIX:

Puisque, après l'appel à la fonction fclose() de toute utilisation des résultats de flux de comportement non défini, la fonction fclose() ne doit pas être utilisé sur stdin, stdout ou stderr, sauf immédiatement avant la fin du processus, ...... S'il y a des atexit() les gestionnaires inscrits par l'application, par exemple un appel à la fonction fclose() ne devraient pas se produire jusqu'à ce que le dernier gestionnaire de finition. Une fois la fonction fclose() a été utilisé pour fermer l'entrée standard stdin, stdout ou stderr, il n'existe pas de méthode standard pour rouvrir une de ces flux.

Utilisation de close() sur les descripteurs de fichier STDIN_FILENO, STDOUT_FILENO ou STDERR_FILENO doit être immédiatement suivie par une opération de rouvrir ces descripteurs de fichiers. ...... En outre, un close (), suivie d'une réouverture de l'opération (par exemple, open(), dup (), etc) n'est pas atomique; dup2() doit être utilisé pour changer la norme de descripteurs de fichiers.

De fermeture du flux sans manipulation ses erreurs n'est pas robuste, et il est le même pour stdout et stderr. Voici une liste des erreurs que vous devez gérer:

• fclose(stdout)
• ferror(stdout) un.k.un. erreur précédente
• __fpending(stdout) un.k.un. choses n'ont pas été vidées

De la manipulation de ces erreurs, comme GNUlib met en œuvre dans proche-stream.cest cité ci-dessous.

int
close_stream (FILE *stream)
{
  const bool some_pending = (__fpending (stream) != 0);
  const bool prev_fail = (ferror (stream) != 0);
  const bool fclose_fail = (fclose (stream) != 0);

  /* Return an error indication if there was a previous failure or if
     fclose failed, with one exception: ignore an fclose failure if
     there was no previous error, no data remains to be flushed, and
     fclose failed with EBADF.  That can happen when a program like cp
     is invoked like this 'cp a b >&-' (i.e., with standard output
     closed) and doesn't generate any output (hence no previous error
     and nothing to be flushed).  */

  if (prev_fail || (fclose_fail && (some_pending || errno != EBADF)))
    {
      if (! fclose_fail)
        errno = 0;
      return EOF;
    }

  return 0;
}

Avis: __fpending est la particularité de la glibc et peuvent ne pas être portable. Otoh, que, c'est sur le chemin pour être normalisé comme fpending.

P. S.:

J'ai juste envie de le stdout et stderr de sortie à un fichier journal au lieu de la console.

Ce n'est pas une raison pour fermer la sortie standard stdout et stderr si vous écrivez un démon selon http://cloud9.hedgee.com./scribbles/daemon#logging. Vous devriez laisser un gestionnaire du démon (comme daemon tools, runit, s6, bouffe, OpenRC et systemd) gérer la redirection.

Cependant, vous devez fermer les flux que le programme n'a jamais écrit à la fin pour vérifier les erreurs. Citation de proximité-stream.c:

Si un programme écrit rien à FLOT, que le programme doit fermer
FLUX et assurez-vous qu'il réussit avant de quitter. Sinon,
supposons que vous aller à l'extrême de la vérification de l'état de retour
de chaque fonction qui n'explicite de l'écriture de FLUX. La dernière
printf peut réussir dans l'écriture à l'intérieur de la mémoire tampon, et encore
la fonction fclose(STREAM) pourrait encore échouer (dus, par exemple, pour un disque plein d'erreur)
lorsqu'il tente d'écrire que les données mises en mémoire tampon. Ainsi, vous serait
à gauche incomplète du fichier de sortie et de la délinquance programme serait
sortie avec succès. Même l'appel de fflush n'est pas toujours suffisant,
depuis certains systèmes de fichiers (NFS et CODA) tampon écrit/vidées de données
jusqu'à ce qu'un réel appel à proximité.

En outre, il est fastidieux de vérifier la valeur de retour de chaque appel
qui écrit pour STREAM -- il suffit de laisser le flux interne de l'état d'enregistrement
la panne. C'est ce que l'ferror test est de vérifier ci-dessous.