cat < filewypisuje zawartość pliku na standardowe wyjście.
cat > fileodczytuje stdin aż do wykrycia Ctrl+ Di zapisania tekstu wejściowego do pliku .
cat <> file, przynajmniej w mojej wersji Bash, drukuje zawartość pliku szczęśliwie (bez błędów), ale nie modyfikuje pliku ani nie aktualizuje znacznika czasu modyfikacji.
W jaki sposób standard Bash uzasadnia pozornie ignorowane >w trzecim stwierdzeniu - a co ważniejsze, czy coś robi ?
Odpowiedzi:
Bash używa <>do utworzenia deskryptora pliku do odczytu i zapisu :
Operator przekierowania
[n]<>wordpowoduje, że plik, którego nazwa jest rozwinięciem słowa, jest otwierany zarówno do odczytu, jak i zapisu na deskryptorze pliku n lub na deskryptorze pliku 0, jeśli nie określono n. Jeśli plik nie istnieje, jest tworzony.
cat <> fileotwiera fileodczyt-zapis i wiąże go z deskryptorem 0 (standardowe wejście). Jest to zasadniczo odpowiednik < filekażdego rozsądnie napisanego programu, ponieważ nikt prawdopodobnie nie spróbuje pisać na standardowym wejściu, ale gdyby tak się stało, byłoby to możliwe.
Możesz napisać prosty program w C, aby przetestować to bezpośrednio - write(0, "hello", 6)zapisze hellosię fileza pomocą standardowego wejścia.
<>powinien również działać w dowolnej innej powłoce zgodnej z POSIX z tym samym efektem.
4<>file) jest przydatne i przypuszczam, że 0 jest tak samo dobrym ustawieniem, jak każde, gdy go pominiesz. Czytanie ze standardowego wyjścia nie jest lepsze.
<>jest również przydatny w niektórych systemach (np. Linux) do otwierania nazwanych potoków bez blokowania, dopóki inny proces nie otworzy go do zapisu.
<>Operator może być przydatny przy pisaniu aplikacji, która działała z kilkoma terminalami i czasami chciał uruchomić powłokę. Ta powłoka z kolei nie byłaby w stanie uruchamiać aplikacji uruchamianych ze zwykłego terminala sterującego, chyba że mogłaby skorzystać z <>... takiego jak ... pager more, który odczytuje ze standardowego błędu, aby uzyskać swoje polecenia, a więc standardowe wejście i standardowe wyjście oba są dostępne do ich zwykłego użytkowania. cat food | more - >/dev/tty03 2<>/dev/tty03
<> fileotwiera plik (domyślnie na deskryptorze pliku 0 (stdin), jak <) w trybie do odczytu i zapisu bez obcinania i tworzenia pliku, jeśli wcześniej nie istniał .
To odpowiada O_RDWR|O_CREATflagom przekazywanym do open()wywołania systemowego. Natomiast <jest O_RDONLYi >jest O_WRONLY|O_CREAT|O_TRUNCi >> O_WRONLY|O_CREAT|O_APPEND.
Zapisywanie standardowego wejścia nie jest często przydatne, ponieważ aplikacje zwykle nie piszą na standardowe wejście. Aplikacje zwykle nie oczekują odczytu i zapisu na deskryptorze pliku, który otrzymują podczas uruchamiania; zwykle czytają ze stdin (lub deskryptora pliku, który sami otwierają) i piszą na stdout lub stderr (lub deskryptorze pliku, który sami otwierają).
<> może mieć swoje zastosowania:
cat <> filewięcej, cat < filejeśli nie chcesz, aby polecenie zakończyło się niepowodzeniem, jeśli filenie istnieje, ale filezamiast tego utworzono puste .Niecięty aspekt <>sprawia, że przydatne jest zastępowanie plików w miejscu. W takim przypadku jednak zazwyczaj nie używasz go w deskryptorze pliku 0:
printf xxx 1<> filezastępuje pierwsze 3 bajty filez xxx.
W niektórych systemach, takich jak Linux, <>na nazwanym potoku (FIFO) otwiera nazwany potok bez blokowania (bez oczekiwania na inny proces otwarcia drugiego końca) i zapewnia, że struktura potoku pozostanie przy życiu. Na przykład w:
mkfifo pipe; sed 's/foo/bar/g' <> pipesedobsługuje przychodzące dane z dowolnej liczby innych procesów zapisujących się na nich i nigdy ich nie widzi eof.
<>domyślnie jest ustawiony na 1<>(standardowe wyjście) zamiast 0<>(standardowe wejście ). Jest to błąd zgodności z POSIX, który zgłosiłem i zostanie naprawiony w następnej wersji. github.com/att/ast/issues/75 Ale dopóki bieżące wersje ksh93 nie przestaną być używane, musisz podać numer deskryptora pliku, aby używać go <>przenośnie.
mkfifo fifo; exec 3<>fifomiałyby się blokować?