From owner-freebsd-current Mon Apr 10 10:15:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA12513 for current-outgoing; Mon, 10 Apr 1995 10:15:25 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA12507 for ; Mon, 10 Apr 1995 10:15:23 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA23903; Mon, 10 Apr 95 11:08:58 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504101708.AA23903@cs.weber.edu> Subject: Re: talk - mesg y only To: mmead@goof.com (matthew c. mead) Date: Mon, 10 Apr 95 11:08:57 MDT Cc: current@FreeBSD.org In-Reply-To: <199504090335.XAA22901@goof.com> from "matthew c. mead" at Apr 8, 95 11:35:56 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > Why does talk want mesg y all the time? It's not needed to be > able to talk to others. I like to keep messages on on one xterm, > and messages off on everything else, including a talk session - > that way it doesn't interrupt the wrong window. I know I could > just go change this myself (the change is really trivial), but I > thought I might ask if anyone knows another reason it's desirable > (?) to keep this behavior... Because talk requests aren't VMS style broadcasts like "phone" requests. In other words, you could harrass someone by talking them and typing ^C and they couldn't harrass you back. And it doesn't count that they could harrass you back if they picked the right tty, because there's no way to identify a group of ttys (ptys) as "you" (this is a nod to the fact that multiple people can be using the same account simultaneously, as is the tty argument to both talk and write). The argument you appear to be making is that "broadcasts" should go to a single window in a given "session", and because you have them enabled for one window of a session, then you should be allowed to make requests from the other windows as if they also had it enabled. In other words source -> session -> designated_receivers_for_session. Well, talk doesn't know about "sessions", and a generic "broadcast" mechanism would require restructuring a *lot* of software (why do you thing VT200 and VT300 series terminals don't have an escape key?) to guarantee escape sequence atomicity from the computer to the terminal. You'll find that they 'write' command is also SGID tty and follows (or should, anyway) the same behaviour. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.