microsoft | matafan a écrit :
Je pense que c'est parce que ctrl-d n'indique la fin de fichier que s'il est entré en début de ligne. Si tu n'est pas en début de ligne, ctrl-d va simplement envoyer la ligne.
Quand tu lances ton programme, la ligne est vide. Si tu tapes ctrl-d, le programme va sortir tout de suite. Si tu tapes du texte, rien ne se passe dans ton programme. Il est simplement bloqué dans getchar(), en attente de quelque chose à lire. Quand tu tapes ctrl-d, la ligne (le texte que tu as tapé jusque là) est mise dans le buffer d'entrée et ta boucle dépile les caractères les uns après les autres. Jusqu'au dernier, et à ce moment tu te retrouves dans la situation initiale avec un buffer d'entrée vide et un getchar() bloqué en attente de caractère. C'est reparti pour un tour : si tu tapes ctrl-d tu sors (c'est ton deuxième ctrl-d successif), si tu tappes du texte il te faudra à nouveau deux ctrl-d supplémentaire pour sortir : un pour envoyer la ligne, et un en début de ligne pour signifier EOF.
Je suis clair ?
|
Merci de ton explication , je n'ai pas encore tout compris à vrai dire (je manque de connaissances en la matière), car je ne pensais pas la fonction getchar utilisait un buffer.
En fait, je pensais travailler caractère par caractère (je veux dire comme si à chaque boucle la nouvelle valeur stockée par getchar remplaçait l'ancienne).
Si j'ai bien compris (ou pas), le ctrl+d agit comme un espèce de retour chariot, permettant de vider le buffer d'entrée ?
Je vais essayer de trouver un peu plus d'infos sur le fonctionnement de getchar. ---------------
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse"
|