Co robi nagi <?

bash nie wydaje się narzekać, jeśli uruchomisz polecenie takie jak

$ < some-file-that-exists

Wydaje się, że nic się nie dzieje.

Możesz także użyć

$ <<<"any string"

a nawet proces zastępowania.

Co dokładnie to robi i dlaczego jest dozwolone. Czy może się przydać do czegoś?

bash

— Pigułki przeciwwybuchowe
źródło

BTW: Dla wielkiego ZSH „<foobar” jest tym samym, co „mniej foobar”, jako twój przekierowany foobar do powłoki. Myślę, że jest to dość intuicyjne zachowanie. Nagie <wyświetli błąd ( zsh: parse error near `\n'), ponieważ nie podano żadnego argumentu.

— matematyka

@math pojawi się podobny błąd bash, ale to jest interesujące less.

— Tabletki przeciwwybuchowe

Odpowiedzi:

<ustawia przekierowanie dla polecenia, które może wystąpić przed instrukcją przekierowania lub po niej. To znaczy

$ < file wc

działa również

$ wc < file

Ale jeśli nie wydasz polecenia, bash konfiguruje przekierowanie i nie robi nic innego. W przypadku przekierowania wejściowego odpowiada to temu, co widziałeś, nic, jeśli plik istnieje i jest czytelny. Jeśli plik nie istnieje lub nie można go odczytać, bash zasygnalizuje błąd. W przypadku przekierowania danych wyjściowych plik wyjściowy zostanie utworzony, jeśli nie istnieje. Każdy istniejący plik wyjściowy zostanie obcięty, jeśli >zostanie użyty; bez obcięcia, jeśli >>jest używane.

— Kyle Jones
źródło

innymi słowy, są one zwięzłe, istnieją i tworzą

— maniakiem zapadkowym,

@Kyle Jones Myślę, że w ostatnim zdaniu nie pasowałeś do dwóch operatorów.

— jamesbtate

@Puddingfox Thanks. Zredagowałem zdanie końcowe na końcu, aby wyjaśnić.

— Kyle Jones

Czy istnieje jakikolwiek powód, aby korzystać < file wcVs. wc < file?

— Pigułki przeciwwybuchowe

@ tandu Przydaje się przy korzystaniu z interaktywnych powłok. Załóżmy, że masz polecenie przekierowujące i chcesz je powtórzyć z innym ostatnim argumentem. Jeśli przekierowanie znajduje się na początku wiersza, łatwo jest wpisać control-P, a następnie edytować ostatni argument bez konieczności przeskakiwania języka „<foo> takt 2> i 1”, jak gdyby to było na końcu. Poza tym nie znalazłem dla niego żadnego pożytku.

— Kyle Jones

<domyślnie czyta ze standardowego wejścia lub pliku. twoje wyrażenie nic nie robi z danymi wejściowymi, ponieważ nic nie zrobiłeś po przeczytaniu.

jeśli zrobisz na końcu plik wyjściowy <jakiś plik, który istnieje>, zobaczysz, że właśnie przeczytałeś zawartość pierwszego pliku i zapisałeś go do drugiego pliku.

<<< jest tutaj formatem doc, więc czyta z ciągu zamiast z pliku. kot <<< „dowolny ciąg”, aby zobaczyć, co przeczytałeś.

— johnshen64
źródło

na przyszłość, edytuj swoją odpowiedź, aby dodać szczegóły zamiast dodawać komentarz

— Nate Koppenhaver,

„jeśli zrobisz na końcu plik wyjściowy <jakiś plik, który istnieje>, zobaczysz, że właśnie przeczytałeś zawartość pierwszego pliku i zapisałeś go do drugiego pliku.” To jest źle; bez polecenia plik wyjściowy zostanie obcięty do zera bajtów.

— Kyle Jones