Czytam tutaj, że to powinno działać, ale to nie:
# usage: wall [file]
root@sys:~> mesg
is y
root@sys:~> wall "who's out there"
wall: can't read who's out there.
Jeśli mesgjest ustawiony na y, co uniemożliwia mi nadawanie łańcucha? Uwaga: potwierdziłem, że opcja pliku działa:
root@sys:~> wall test
Broadcast Message from root@sys (/dev/pts/1) at 15:23 ...
Who's out there?
Odpowiedzi:
Problem leży w składni użytej w połączonym artykule. Aby zrozumieć, co dokładnie idzie nie tak, spójrzmy na man wall:
Zastosowanie od man wall:
wall [file]
Wall displays the contents of file or, by default, its standard input
wallPrzyjmuje więc jedno z dwóch źródeł wiadomości.
Dowolny podany argument wiersza poleceń wallmusi być nazwą pliku. Ponieważ nie ma wiarygodnego sposobu, aby stwierdzić, czy argument ma oznaczać wiadomość lub nazwę pliku, wallprzyjmie, że jest to ta ostatnia, zignoruje wszystko przychodzące na standardowe wejście i spróbuje odczytać wiadomość z tego pliku.
W danym przypadku próbuje odczytać z pliku who's out therei nie znajduje go. Pamiętaj, że odczyt z pliku jest zwykle ograniczony do administratora. Gdybyś był wykonany wall "who's out there"jako użytkownik nieuprzywilejowany, prawdopodobnie jego wyniki byłyby,wall: will not read who's out there - use stdin.
Jeśli nie otrzyma argumentu nazwy pliku w wierszu poleceń, rozpocznie czytanie ze standardowego wejścia. Istnieje kilka sposobów przekazywania informacji do standardowego wejścia komendy. Jednym z nich jest użycie potoku UNIX . Potok połączy standardowe wyjście polecenia po lewej stronie ze standardowym wejściem polecenia po prawej stronie:
$ echo "who's out there" | wall
Innym sposobem jest użycie dokumentu tutaj . A here documentjest konstrukcją powłokową, która przekazuje ciąg znaków (do określonego znacznika końcowego we własnej linii) bezpośrednio do standardowego wejścia polecenia, bez pośredniego kroku posiadania odrębnego polecenia generującego ten wynik:
$ wall << .
who's out there?
.
Byłoby to „bezużyteczne użycie tutaj dokumentów”, ponieważ domyślnie sam terminal zostanie podłączony do wallstandardowego wejścia i wallzacznie z niego czytać, dopóki nie otrzyma znaku końca pliku ( Ctrl+D):
$ wall
who's out there?
^D
Jak zauważył Rich Homolka w komentarzach, niektóre powłoki obsługują, here stringsktóre pozwalają na przekazanie dosłownego ciągu znaków bez poleceń lub znaczników końcowych:
$ wall <<< "who's out there?"
Wszystkie przesyłają coś do wallstandardowego wejścia. Różnica polega na tym, że potok łączy z nim dane wyjściowe innego polecenia here documentsi here stringsprzekazuje ciąg bezpośrednio. Zaletą tych dwóch ostatnich jest tutaj walor estetyczny, ponieważ echopolecenie z przykładu potoku jest wbudowanym poleceniem powłoki, więc będzie powłoką zapewniającą walldane wejściowe we wszystkich przypadkach.
wall <<< stringPetha widzę teraz, że oferowałeś sintax. To całkiem nieźle. Czy któryś z was może wyjaśnić, co <<<dokładnie robi (i dlaczego byłoby to bardziej wydajne, jak powiedział peth)? Wydaje mi się dziwne, że cmd, który wymaga pliku, może zaakceptować ciąg znaków <<<. Dzięki jeszcze raz.
wallakceptuje go (ściana odczytuje ze standardowego wejścia, jeśli nie t określić plik). W celu sprawdzenia, czy tustrowie tworzą plik, $ readlink /proc/self/fd/0 <<< testwydrukuje coś podobnego /tmp/sh-thd-4228536315 (deleted).
spróbuj z rootem
root@username:~# wall /home/username/yourfile_name
jeśli plik znajduje się w katalogu domowym, spróbuj innej ścieżki
echo xxx | yyyskładni, co uważam za niepotrzebnewall <<<'your message'