[TAG] suppress terminal messages of other processes

[Mike Orr]

On Wed, Feb 18, 2004 at 04:13:05PM +0100, Christoph Sandhaus wrote:
> system: Caldera Open Linux (V3.1.1, server) (sorry for that, will change 
> soon!)

No need to apologize.  Caldera's first sin (standing alone rather than
interacting much with other Linux distributions/users) was pretty minor,
especially since (1) when they finally got their act together they
articulated that they were going after vertical niches rather than the
general distribution market, (2) they were in the process of building
open-source projects to contribute back to Linux.  (There was one major
one, I can't remember the details now, I think something like an online
software catalog, but it stalled and I don't think it was ever completed.)

SCO's current sins are not Caldera's fault, since they could only happen
after the Caldera-minded members were forced out or suppressed.

> kernel messages (i.e.: "printk()", "echo stuff | wall") can't be suppressed: 
> structured output is destroyed
> -
> custom scsi kernel modul will be changed, but system error messages are still 
> active
> -
> messages like your example ("cannot load module char-major-10-175") still pass 
> trough
> -
> once there was a network module (3c5xx maybe?, unsure right now): unplug the 
> network cable => "... has diconnected"

One workaround would be to use a GUI window (wxPython, Tkinter, gtk, etc) for
your application output.  Kernel messages can't write there.

> Maybe I'v got an idea:
> Doesn't the messages (i.e. from wall) arrive trough STDERR?
> Is there a possibility to ignore incoming messages on STDERR on a xterm?

Stderr is a channel a process writes out on, not a channel it receives
things from.  So xterm cannot receive things on stderr.  It does receive
things from stdin, but that's connected to the tty xterm was started *from*,
not to the tty that xterm's display window is showing.  Stdin/stdout/stderr
are set by the kernel when xterm starts, and only later does xterm allocate
a tty for its display window.  If xterm receives something on stdin, it
probably ignores it.  But if it receives something on the tty connected to
its window, it displays it.  You can do this yourself.

``
% echo "abc" >/dev/tty
abc
% tty
/dev/pts/7
% echo "abc" >/dev/pts/7
abc
% echo "abc" >/dev/pts/8
zsh: permission denied: /dev/pts/8
% w
 09:46:21 up 2 days,  9:22,  2 users,  load average: 0.06, 0.04, 0.01
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
iron     tty1     -                Mon05    2days  3:15   0.03s  /bin/sh /usr/X1
iron     pts/7    :0.0             22:09    0.00s  0.98s  0.04s  w 
% echo "abc" >/dev/tty1
% echo "abc" >/dev/tty7
% 
''

(/dev/tty automatically directs to the current tty.  The 'tty' command
shows which tty is the current one.  I got a permission error because I
don't own /dev/pts/8.  The first 'w' entry is the console I ran "startx"
in.  Writing to it didn't show up here, but it did show up in my text
console.  /dev/tty7 is the graphical display my X session is using, thus
the one konsole was launched from, thus konsole's stdin/stdout/stderr.
Writing to it didn't show up in the window, it just disappeared.  In all
cases, 'echo' is writing to its stdout, not to its stderr.  The tty it's
writing *to* may be somebody else's stdin or stderr, but that depends on
how that other somebody is configured.)

I use konsole, which is kind of a super xterm from KDE.  Each konsole 
has multiple views (like screen), but sometimes I launch a second
konsole from the first so I can keep two sets of views separate.  For
instance, one set of views for my personal stuff, and another set for
work stuff (which are all su'd to another user).  The second konsole
writes all sorts of undesired debugging information on stderr, which
stomps over the view I launched it from -- similar to the problem 
you're having.  So I start it with "konsole 2>/dev/null" to suppress
those messages.  But that only works if you do it to the process that's
writing the messages.  You can't do that to the kernel, to a driver or
a daemon, since you don't have control over their stdin/stdout/stderr.

-- 
-Mike Orr (aka. Sluggo), mso at oz.net  (iron at sense-sea-MegaSub-1-465.oz.net)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol