Confus à propos de stdin, stdout et stderr?

il serait plus correct de dire que stdin , stdout , et stderr sont" I/O streams " plutôt que les fichiers. Comme vous l'avez remarqué, ces entités ne vivent pas dans le système de fichiers. Mais l' La philosophie d'Unix, en ce qui concerne les e/s, est "tout est un fichier". Dans la pratique, cela signifie vraiment que vous pouvez utiliser les mêmes fonctions et interfaces de bibliothèque ( printf , scanf , read , write , select , etc.) sans se soucier de savoir si les I/O flux est connecté à un clavier, un fichier disque, une socket, un tuyau, ou une autre abstraction d'e/s

la plupart des programmes doivent lire les entrées, écrire les sorties et enregistrer les erreurs, donc stdin , stdout , et stderr sont prédéfinis pour vous, comme une commodité de programmation. Ce n'est qu' une convention, et n'est pas appliquée par le système d'exploitation.

je crains que votre compréhension soit complètement à l'envers. :)

pensez à "standard in", "standard out", et "standard error" du point de vue du programme , pas du point de vue du noyau.

quand un programme a besoin d'Imprimer la sortie, il imprime normalement"standard out". Un programme imprime typiquement la sortie à la norme avec printf , qui imprime seulement à la norme.

Lorsqu'un programme a besoin d'imprimer des informations d'erreur (pas nécessairement des exceptions, celles-ci sont une construction de langage de programmation, imposée à un niveau beaucoup plus élevé), il imprime normalement en "erreur standard". Il le fait normalement avec fprintf , qui accepte un flux de fichiers à utiliser lors de l'impression. Le flux de fichier peut être n'importe quel fichier ouvert en écriture: standard, standard d'erreur, ou tout autre fichier qui a été ouvert avec fopen ou fdopen .

"standard" est utilisé lorsque le fichier doit lire input, utilisez fread ou fgets , ou getchar .

N'importe lequel de ces fichiers peut être facilement redirigé à partir du shell, comme ceci:

cat /etc/passwd > /tmp/out     # redirect cat's standard out to /tmp/foo
cat /nonexistant 2> /tmp/err   # redirect cat's standard error to /tmp/error
cat < /etc/passwd              # redirect cat's standard input to /etc/passwd

Ou, toute l'enchilada:

cat < /etc/passwd > /tmp/out 2> /tmp/err

il y a deux mises en garde importantes: premièrement," standard in"," standard out "et" standard error " ne sont qu'une convention. Ils sont un très fort convention, mais ce n'est qu'un accord sur le fait qu'il est très agréable de pouvoir exécuter des programmes comme celui-ci: grep echo /etc/services | awk '{print ;}' | sort et d'avoir les sorties standards de chaque programme connectés à l'entrée standard du prochain programme dans le pipeline.

Deuxièmement, j'ai donné les fonctions ISO C standard pour travailler avec les flux de fichiers ( FILE * objets) -- au niveau du noyau, ce sont tous les descripteurs de fichiers ( int références à la table de fichiers) et des opérations de niveau beaucoup plus bas comme read et write , qui ne font pas le tampon heureux des fonctions ISO c. J'ai pensé que pour rester simple et utiliser les fonctions les plus faciles, mais je pensais quand même que vous devriez connaître les alternatives. :)

en complément des réponses ci-dessus, voici un résumé des Redirections:

stdin

lit l'entrée à travers la console (par exemple L'entrée au clavier). Utilisé en C avec scanf

scanf(<formatstring>,<pointer to storage> ...);

stdout

produit une sortie vers la console. Utilisé en C avec le printf

printf(<string>, <values to print> ...);

stderr

produit une sortie "erreur" vers la console. Utilisé en C avec fprintf

fprintf(stderr, <string>, <values to print> ...);

Redirection

la source de stdin peut être redirigée. Par exemple, au lieu de provenir d'une entrée clavier, elle peut provenir d'un fichier ( echo < file.txt ), ou d'un autre programme ( ps | grep <userid> ).

les destinations pour stdout, stderr peuvent également être redirigées. Par exemple stdout peut être redirigée vers un fichier: ls . > ls-output.txt , dans ce cas, la sortie est écrite dans le fichier ls-output.txt . Stderr peut être redirigé avec 2> .

en utilisant ps-aux révèle les processus courants, tous listés dans /proc /as/proc/ (pid)/, en appelant cat/proc/(pid)/fd / 0 il imprime tout ce qui se trouve dans la sortie standard de ce processus je pense. Alors peut-être,

/proc/(pid)/fd / 0 - fichier de sortie Standard

/ proc / (pid)/fd / 1 - Fichier D'entrée Standard

/ proc / (pid) / fd / 2 - Fichier D'erreur Standard

par exemple

mais cela n'a bien fonctionné que pour / bin / bash les autres processus n'avaient généralement rien en 0 mais beaucoup avaient des erreurs écrites en 2

je pense que les gens qui disent que stderr ne doit être utilisé que pour les messages d'erreur sont trompeurs. Il devrait également être utilisé pour les messages informatifs qui sont destinés à l'utilisateur qui exécute la commande et non pour les consommateurs potentiels en aval des données (c.-à-d. Si vous exécutez un pipe shell enchaînant plusieurs commandes, vous ne voulez pas que les messages informatifs comme "getting item 30 of 42424" d'apparaître sur stdout car ils vont confondre le consommateur, mais vous pourriez toujours vouloir que l'utilisateur de les voir.

Voir http://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout pour la justification historique:

" tous les programmes ont placé des diagnostics sur la sortie standard. Cela a toujours causé des problèmes lorsque la sortie a été redirigée dans un fichier, mais est devenu intolérable lorsque la sortie a été envoyée à un processus sans méfiance. Néanmoins, ne voulant pas violer la simplicité du modèle standard-input-standard-output, les gens toléré cet état de fait à travers v6. Peu après Dennis Ritchie a coupé le nœud gordien en introduisant le fichier d'erreur standard. Ce n'était pas assez. Avec pipelines diagnostics pourraient provenir de l'un de plusieurs programmes fonctionnant simultanément. Diagnostics nécessaires pour s'identifier."

stderr ne fera pas de mise en tampon de Cache IO de sorte que si notre application a besoin d'imprimer des informations de message critiques (quelques erreurs ,exceptions) à la console ou au fichier l'utiliser où que l'utilisation stdout pour imprimer des informations générales de journal comme il utilise la mise en tampon de Cache IO, il ya une chance que avant d'écrire nos messages à l'application de fichier peut fermer ,laissant complexe débogage

pour des informations faisant autorité sur ces fichiers, consultez les pages de manuel, lancez la commande sur votre terminal.

$ man stdout 

Mais pour une réponse simple, chaque fichier est:

stdout pour un flux de

stdin pour un flux d'entrée

stderr pour les erreurs d'impression ou l'enregistrement des messages.

chaque unix le programme comporte chacun de ces volets.

un fichier avec des tampons associés est appelé un flux et est déclaré être un pointeur vers un fichier de type défini. La fonction fopen () crée certaines données descriptives pour un flux et renvoie un pointeur pour désigner le flux dans toutes les transactions ultérieures. Normalement, il y a trois flux ouverts avec des pointeurs constants déclarés dans l'en-tête et associés aux fichiers ouverts standard. Au démarrage du programme, trois flux sont prédéfinis et n'ont pas besoin d'être ouverts explicitement: lire l'entrée conventionnelle), la sortie standard (pour l'écriture de la sortie conventionnelle), et l'erreur standard (pour l'écriture de la sortie diagnostique). Lorsqu'il est ouvert, le flux d'erreurs standard n'est pas complètement amorti; les flux d'entrées et de sorties standard sont entièrement amortis si et seulement si le flux peut être déterminé qu'il ne se réfère pas à un dispositif interactif

https://www.mkssoftware.com/docs/man5/stdio.5.asp