2

I can't find an answer for this and it may be because I don't know how to phrase the question.

I'm using wall to broadcast a message to open terminals once a day. When it does, the terminal users' prompts will disappear until they press ENTER. The wall command is

wall -n wall message

And for lack of a better explanation, here is what it looks like on the users' terminal:

enter image description here

As you can see it just hangs. Pressing ENTER or doing anything will get me back to a prompt. In fact, even though it doesn't look like a prompt, it is, because instead of pressing ENTER I can do a command, or press up arrow to see previous commands, etc.

It's not critical, it just bugs me. I have considered that maybe it's by design, to force users to acknowledge that they've seen the message, although the fact that it only looks like it's not a prompt seems like it defeats that purpose.

felwithe
  • 882
  • 1
  • 7
  • 12
  • 2
    The shell doesn't know you printed something to its terminal. – Michael Homer Mar 18 '18 at 02:22
  • See also: [How to read/write to tty* device?](https://unix.stackexchange.com/q/138342/73093), particularly the first example in the answer. – Michael Homer Mar 18 '18 at 02:27
  • @MichaelHomer So the answer is if I want to avoid this behavior, I should rig something up printing directly to ttys. All right. – felwithe Mar 18 '18 at 02:54
  • 1
    No, the answer is you're out of luck. – Michael Homer Mar 18 '18 at 02:55
  • 1
    it's not a prompt. it's just text displayed on the terminal - the original prompt is still there, waiting for input in exactly the same state as it was in before the `wall` text was displayed. this means, e.g., that if there was a partially typed command then pressing enter is exactly the wrong thing to do. pressing up arrow followed by down arrow is probably the best thing to do to get the edit line displayed properly again. – cas Mar 18 '18 at 02:55
  • @MichaelHomer Haha ok. I can accept that. – felwithe Mar 18 '18 at 03:18
  • Has everyone here forgotten about `mesg`? – JdeBP Mar 18 '18 at 11:36
  • @JdeBP `mesg n` conflicts with the OP's intention of broadcasting a message to all logged in users. Also, if the `wall` is being run with root privs, that overrides `mesg n` anyway. – cas Mar 18 '18 at 23:14
  • That's _not_ the questioner's intention. See what is buried in an answer comment. – JdeBP Mar 21 '18 at 22:32

1 Answers1

2

What you're experiencing is simply a consequence of how the console is shared by background processes: any process that is running with access to your console can do the same thing. Because the output is happening from a process other than the shell, it doesn't know that the text is there! If you're in an editor, you'll get this text too.

To see this in a controlled environment, try the following:

$ (sleep 5; echo -e "\n\nWhere did this come from?") &
[1] 18898
$ ping localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.039 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.027 ms


Where did this come from?
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.028 ms
64 bytes from localhost (::1): icmp_seq=4 ttl=64 time=0.033 ms
64 bytes from localhost (::1): icmp_seq=5 ttl=64 time=0.028 ms
^C
--- localhost ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4099ms
rtt min/avg/max/mdev = 0.027/0.031/0.039/0.004 ms
[1]+  Done                    ( sleep 5; echo -e "\n\nWhere did this come from?" )
$

Obviously ping didn't print "Where did this come from?"; it came from the background process.

ErikF
  • 3,942
  • 1
  • 10
  • 15
  • I noticed that it prints even in an editor; in fact, my script checks if I have an editor open first, and if I do, it doesn't broadcast the message. – felwithe Mar 18 '18 at 02:50
  • If instead of running `ping` with the above example, you don't do anything, you'll get the same results as what your screenshot showed. Hopefully this helped. – ErikF Mar 18 '18 at 03:04