Dziwne zachowanie d-control

9

Mogę używać tego catjako bardzo prostego edytora tekstu cat > foo.txt.
Jeśli wtedy wpiszę:

bar
baz

a następnie naciśnij ctrl+ D, teraz wygląda to tak:

$ cat > foo.txt
bar
baz^D

z kursorem na ^. Jeśli naciśniemy go jeszcze raz, plik zostanie zapisany. Jeśli jednak cokolwiek nacisnę (okej, może nic, ale przede wszystkim cokolwiek), po prostu kontynuuję edycję pliku.

Czy to jest normalne zachowanie?

bash keyboard-shortcuts cat

— Tyilo
źródło

13

Tak. Ma to ^Dnaprawdę związek z faktem: po prostu zatrzymuje bieżące read(2)połączenie.

Jeśli program tak zrobi int rdbytes = read(fd, buffer, sizeof buffer);i naciśniesz ^Dmiędzy nimi, read()powróci z aktualnie odczytanymi bajtami w buforze, zwracając ich liczbę. To samo dzieje się w przypadku zakończenia linii; \nna końcu zawsze jest dostarczona.

Tak więc tylko ^Dna początku linii lub po innej ^Dma pożądany efekt read()powrotu 0, sygnalizując EOF.

— glglgl
źródło

Zależy to od tego, czym zdefiniujesz linię (z końcowym lub bez końcowego), \nale możesz po prostu nacisnąć ^Ddwa razy pod rząd i spowodować warunek EOF bez generowania końcowego znaku nowej linii (jak naciśnięcie Enter przed ^Dwykonaniem).

— Peter.O,

Masz rację, zapomniałem wspomnieć, że: Początek wiersza i „właśnie wciśnięty ^ D” to dwie sytuacje, w których bufor jest pusty, więc ^ D będzie miał znak read()powrotu 0, wskazując EOF.

— glglgl,

11

Tak, to jest normalne zachowanie. Pojedynczy Control-D zwykle wybucha tylko wtedy, gdy jest to początek linii. To kończy się z jednym Control-D:

$ cat > foo.txt
bar
baz
^D

— Klox
źródło

Control-D dwa razy na końcu linii się

— wybucha

Tak, masz rację. Nie chciałem sugerować inaczej. Zredagowałem swoją odpowiedź, aby wyjaśnić.

— Klox