Ho letto qui che dovrebbe funzionare, ma non:
# usage: wall [file]
root@sys:~> mesg
is y
root@sys:~> wall "who's out there"
wall: can't read who's out there.
Se mesgimpostato su y, cosa mi impedisce di trasmettere una stringa? Nota, ho confermato che l' opzione del file funziona:
root@sys:~> wall test
Broadcast Message from root@sys (/dev/pts/1) at 15:23 ...
Who's out there?
Risposte:
Il problema risiede nella sintassi utilizzata nell'articolo collegato. Per capire cosa non va esattamente, diamo un'occhiata a man wall:
Utilizzo da man wall:
wall [file]
Wall displays the contents of file or, by default, its standard input
Quindi wallaccetta una delle due fonti per il suo messaggio.
Qualsiasi argomento della riga di comando fornito walldeve essere un nome file. Poiché non esiste un modo affidabile per capire se l'argomento è inteso come messaggio o nome del file, wallsupporrà che sia l'ultimo, ignora qualsiasi cosa arrivi sull'input standard e prova a leggere il messaggio da quel file.
Nel caso specifico, prova a leggere dal file who's out theree non lo trova. Si noti che la lettura da un file è in genere limitata al superutente. Se tu fossi stato eseguito wall "who's out there"come utente non privilegiato, probabilmente il suo output sarebbe stato,wall: will not read who's out there - use stdin.
Se non ottiene un argomento relativo al nome del file sulla sua riga di comando, inizierà la lettura dall'input standard. Esistono diversi modi per fornire informazioni all'input standard di un comando. Uno è usare una pipe UNIX . Una pipeline collegherà l'output standard del suo comando sul lato sinistro all'input standard del suo comando sul lato destro:
$ echo "who's out there" | wall
Un altro modo è utilizzare un documento qui . A here documentè un costrutto shell che passa una stringa (fino a un marcatore finale specificato su una riga a sé stante) direttamente all'input standard di un comando, senza che il passaggio intermedio di avere un comando distinto produca quell'output:
$ wall << .
who's out there?
.
Questo sarebbe un "uso inutile dei documenti qui", perché per impostazione predefinita il terminale stesso sarà collegato wallall'input standard e wallinizierà a leggere da esso fino a quando non riceverà un carattere di fine file ( Ctrl+D):
$ wall
who's out there?
^D
Come ha osservato Rich Homolka nei commenti, alcune shell supportano here stringsche consentono il passaggio di una stringa letterale senza comando o marker di fine:
$ wall <<< "who's out there?"
Tutti forniscono qualcosa wallall'input standard. La differenza è che un oleodotto collega l'uscita di un altro comando ad esso, mentre here documentse here stringspassare direttamente la stringa. Il vantaggio di questi ultimi due qui è estetico, in quanto il echocomando dell'esempio pipe è un comando incorporato della shell, quindi sarà l' wallinput della shell a fornire in tutti i casi.
wall <<< stringsintassi. È fantastico. <<<Qualcuno di voi può spiegare cosa sta facendo esattamente (e perché sarebbe più efficiente come ha detto peth)? Trovo strano che un cmd che richiede un file possa accettare una stringa dopo <<<. Grazie ancora.
wallaccetta (wall legge da stdin se non si ' t specificare un file). Per verificare che i herestring creino un file, $ readlink /proc/self/fd/0 <<< teststamperanno qualcosa del genere /tmp/sh-thd-4228536315 (deleted).
prova con root
root@username:~# wall /home/username/yourfile_name
se il tuo file è nella home directory, prova un altro percorso
echo xxx | yyysintassi, che trovo cludgywall <<<'your message'