Dzisiaj eksperymentowałem z kilkoma operacjami dołączania i, z ciekawości, uruchomiłem to (gdzie plik1.txt był niepusty i plik2.txt był pusty):
$ cat file1.txt >> file2.txt >> file1.txt
Kiedy zobaczyłem, że zajmuje to trochę czasu, naciśnij Ctrl+, Caby to zakończyć. Do tego czasu plik1.txt miał setki MB.
Zmiana nazw plików nie daje tego samego efektu; tylko wtedy, gdy pliki są w tej kolejności, następuje nieskończone przekierowanie. Co dokładnie się dzieje, co to powoduje?
Odpowiedzi:
Nie można catw ten sposób użyć wielu standardowych, ostatnie przekierowanie ma pierwszeństwo, więc:
cat file1.txt >> file2.txt >> file1.txt
jest równa:
>> file2.txt ; cat file1.txt >> file1.txt
który oczywiście szybko zapełnia system plików, biorąc pod uwagę fakt, że plik źródłowy będący celem także rośnie w nieskończoność, pod warunkiem, że file1.txtjest wystarczająco duży, aby nie można go było odczytać od razu.
Większość nowoczesnych catimplementacji powinna wykrywać rekurencyjność i przerywać:
Kot Solaris:
cat: input/output files 'file1.txt' identical
Kot GNU:
cat: file1.txt: input file is output file
I tak można ich oszukać za pomocą czegoś takiego:
cat < file1.txt | cat | cat >> file2.txt >> file1.txt
Miłe, nie tak bezużyteczne korzystanie z kotów ...
Nie byłem w stanie odtworzyć tego w powłoce Bash:
# non-empty file1
$ echo 1 > file1.txt
$ cat file1.txt >> file2.txt >> file1.txt
cat: file1.txt: input file is output file
Zostanie utworzony 1 plik o długości 0, ale następnie pojawia się powyższy komunikat:
$ ls -l
total 4
-rw-rw-r-- 1 saml saml 2 Sep 10 19:35 file1.txt
-rw-rw-r-- 1 saml saml 0 Sep 10 19:35 file2.txt
Na podstawie odpowiedzi @ jlliagre nie jestem pewien, dlaczego otrzymuję 2 pliki. Może to zależeć od catwdrożenia.
@jlliagre zaktualizował swoją odpowiedź, aby pokazać ten kod, który uważa za równoważny:
>> file2.txt ; cat file1.txt >> file1.txt
Więc teraz wiem, dlaczego robię się pusta file2.txt. Ta notacja jest legalna:
>> file2.txt
I utworzy pusty plik.
file1.txtzaczynając od niepustego.
catzachowanie.