J'ai lu ici que cela devrait fonctionner, mais ce n'est pas le cas:
# usage: wall [file]
root@sys:~> mesg
is y
root@sys:~> wall "who's out there"
wall: can't read who's out there.
Si mesgest défini sur y, qu'est-ce qui m'empêche de diffuser une chaîne? Remarque, j'ai confirmé que l' option de fichier fonctionne:
root@sys:~> wall test
Broadcast Message from root@sys (/dev/pts/1) at 15:23 ...
Who's out there?
Réponses:
Le problème réside dans la syntaxe utilisée dans l'article lié. Pour comprendre ce qui ne va pas exactement, jetons un œil à man wall:
Utilisation de man wall:
wall [file]
Wall displays the contents of file or, by default, its standard input
wallAccepte donc l' une des deux sources pour son message.
Tout argument de ligne de commande donné à walldoit être un nom de fichier. Comme il n'y a pas de moyen fiable de dire si l'argument est destiné à être un message ou un nom de fichier, wallsupposera que c'est le dernier, ignorez tout ce qui entre sur l'entrée standard et essayez de lire le message de ce fichier.
Dans le cas donné, il essaie de lire le fichier who's out thereet ne le trouve pas. Notez que la lecture d'un fichier est généralement réservée au superutilisateur. Si vous aviez exécuté en wall "who's out there"tant qu'utilisateur non privilégié, sa sortie aurait probablement été,wall: will not read who's out there - use stdin.
S'il n'obtient pas d'argument de nom de fichier sur sa ligne de commande, il commencera la lecture à partir de l'entrée standard. Il existe plusieurs façons de fournir des informations à l'entrée standard d'une commande. L'une consiste à utiliser un tuyau UNIX . Un pipeline connectera la sortie standard de sa commande côté gauche à l'entrée standard de sa commande côté droit:
$ echo "who's out there" | wall
Une autre façon consiste à utiliser un document ici . A here documentest une construction shell qui transmet une chaîne (jusqu'à un marqueur de fin spécifié sur une ligne qui lui est propre) directement à l'entrée standard d'une commande, sans que l'étape intermédiaire consistant à avoir une commande distincte produise cette sortie:
$ wall << .
who's out there?
.
Ce serait une "utilisation inutile des documents ici", car par défaut, le terminal lui-même sera connecté à walll'entrée standard de et wallcommencera à le lire jusqu'à ce qu'il reçoive un caractère de fin de fichier ( Ctrl+D):
$ wall
who's out there?
^D
Comme Rich Homolka l'a noté dans les commentaires, certains shells prennent en charge here stringsqui permettent de passer une chaîne littérale sans commande ni marqueur de fin:
$ wall <<< "who's out there?"
Tous alimentent quelque chose à walll'entrée standard. La différence est qu'un pipeline lui connecte la sortie d'une autre commande, here documentset lui here stringstransmet la chaîne directement. L'avantage des deux derniers ici est d'ordre esthétique, car la echocommande de l'exemple de tuyau est une commande intégrée au shell, donc ce sera le shell qui fournira walll'entrée dans tous les cas.
wall <<< stringoffriez la sintax. C'est plutôt bien. L'un de vous peut-il expliquer ce qu'il <<<fait exactement (et pourquoi ce serait plus efficace comme l'a dit Peth)? Je trouve étrange qu'un cmd qui nécessite un fichier puisse accepter une chaîne après <<<. Merci encore.
wallaccepte (le mur lit à partir de stdin si vous ne le faites pas) t spécifier un fichier). Pour vérifier que les chaînes de caractères créent un fichier, $ readlink /proc/self/fd/0 <<< testimprimera quelque chose comme /tmp/sh-thd-4228536315 (deleted).
essayez avec root
root@username:~# wall /home/username/yourfile_name
si votre fichier se trouve dans le répertoire personnel, sinon essayez un autre chemin
echo xxx | yyysyntaxe, ce que je trouve grossierwall <<<'your message'