Comportement bizarre de contrôle-d

9

Je peux utiliser catcomme un éditeur de texte très simple en faisant cat > foo.txt.
Si je tape alors:

bar
baz

puis appuyez sur ctrl+ D, il ressemble maintenant à ceci:

$ cat > foo.txt
bar
baz^D

avec le curseur sur ^. Si j'appuie à nouveau dessus, le fichier sera enregistré. Cependant, si j'appuie sur quelque chose (d'accord, peut-être pas n'importe quoi, mais surtout n'importe quoi), je continue simplement à éditer le fichier.

Est-ce un comportement normal?

bash keyboard-shortcuts cat

— Tyilo
source

13

Oui. Cela a ^Dvraiment à voir avec : il arrête simplement l' read(2)appel en cours.

Si le programme le fait int rdbytes = read(fd, buffer, sizeof buffer);et que vous appuyez ^Dentre, read()retourne avec les octets actuellement lus dans le tampon, en retournant leur nombre. La même chose se produit sur la terminaison en ligne; le \nà la fin est toujours livré.

Ainsi, seul un ^Dau début d'une ligne ou après une autre ^Da l'effet souhaité d'avoir un read()retour 0, signalant EOF.

— glglgl
source

Cela dépend de ce que vous définissez comme une ligne (avec ou sans fin \n.. mais il est possible d'appuyer simplement ^Ddeux fois de suite et de provoquer une condition EOF sans générer un caractère de nouvelle ligne final (comme en appuyant sur Entrée avant le ^Dfaire).

— Peter.O

Vous avez raison, j'ai oublié de mentionner que: début de ligne et "juste pressé ^ D" sont les deux situations où le tampon est vide, donc ^ D va read()revenir 0, indiquant EOF.

— glglgl

11

Oui, c'est un comportement normal. Un seul Control-D n'éclate normalement que si c'est le début de la ligne. Cela se termine avec un Control-D:

$ cat > foo.txt
bar
baz
^D

— Klox
source

Control-D deux fois à la fin d'une ligne éclate, sans un caractère de fin de ligne ...

— Peter.O

Oui tu as raison. Je ne voulais pas laisser entendre le contraire. J'ai modifié ma réponse pour clarifier.

— Klox