mechanisms exist.

   (?) By adding the last line to your 'profile', users messages are turned on
   by default. I also modify my local '~/.bash_profile' file with the same
   entry since [77]KDE and friends sometimes don't play nice with the global
   settings :) 

     (!) [Ben] Admittedly, setting a global "mesg y" is not something that'll
     accidentally destroy the world, but tweaking /etc/profile, as a rule of
     thumb, is to be approached with much forethought, trepidation, and a stout
     shock prod.

     (!) [Thomas] As to why KDE is ignoring this, you need to make sure that
     you either start $SOME_TERMINAL_EMULATOR invoked as a login shell, so that
     the global files are read. Or, alternatively, source ~/.bashrc from
     ~/.x{session,initrc}

     (!) [Ben] Thomas, to the best of my knowledge, /etc/profile is read as
     soon as you log in, as long as your login shell is anything that had the
     Bourne shell in its family tree. The question of whether you ran an xterm
     or not shouldn't even be applicable. Do you have some information to the
     contrary?

     (!) [Thomas] It is if you login to a console -- not via a DM. Kdm and
     friends are notorious for this. This is why so many people get confused as
     to why their nice $PS1 prompts don't appear in xterms and the like.

     So you either force the shell to be a login-shell, or if you have defined
     various  environment  vars in ~/.bashrc, to source this from within
     ~/.x{session,initrc}

     (!) [Ben] Wow, evil. I've got to say that I'm a bit shocked - why the heck
     would they break a working system that way?

     All the more reason I'm glad I've avoided *dm for all these years, then...

     (!) [Thomas] Break? No, That's exactly the way it should be, Ben. Sure,
     when you open up an xterm, the subshell is supposed to be inheriting
     environment variables from somewhere, but then that's why the user sets it
     up.

     (!) [Ben] The broken part is, why would it have to be set up twice? If
     I've spent time configuring my CLI environment, it shouldn't change if I
     decide that I now want to start X via *dm. Sure, sourcing the rc files
     from ~/.xsession isn't that hard - but you have to know enough to do it.

     (!) [Thomas] The X startup files are not supposed to source anything shell
     related such as /etc/profile by default. Why? It has no reason to -- that
     operation is to do with shells only.

     Of course, as I have said, this is where ~/.xsession shines. :)

     (!) [Ben] Except that, by allowing the user to log in without doing so, it
     now changes his environment without any reason for it - and violates the
     programming principle of doing "the least unexpected" thing.

     (!)  [Kapil]  As  far  as  I  can see, this is one of those "active
     developer/backward compatability" (AD/BC) issues. The AD wanting to move
     to GUI (yes, it was a while ago but we CLI types don't die easy :) )
     Unfortunately, when the "shell" was designed it was assumed (ah-ha!) that
     no  one  would  run  programs  (except daemons) other than from the
     command-line or from other running programs and so on recursively.

     One solution. Have a file say $HOME/.environ and ensure that it is sourced
     at all session-startups CLI or GUI.

     (!) [Thomas] But this is why /etc/environment is used. If PAM is setup to
     use it, then it will. We're fortunate that /etc/environment in this
     instance is the only shell-agnostic file available. So it is ideal for
     these sorts of situations. Although it should not be mis-used. It's also
     not very portable.

     (!) [Kapil] So why not use $HOME/.profile instead. Not because of (t)csh
     folks :-) The problem would be that a .profile could do a number of CLI
     specific thnigs---in fact shell users have had extremely complicated
     .profile's in the past. It is a mess as any AD/BC issue generally is.

     The problem with TLU thing is to decide who the target user is---the one
     who read the part of the manual which said "keep .profile simple" or the
     one who read the juicy bits about all the fancy features of the latest
     shell and didn't enclose those in "if [ -n "$PS1" ] ... fi". The latter's
     X session will probably crash if her/his .profile is sourced.

     I think there was long thread on Debian once about /etc/environment but
     IIRC the idea was dropped. Perhaps (I tremble to start another war here)
     PAM's session mechanism could be used to setup session variables.

   (?) Heh, I avoided *dm's too until I started back to scewl (~40ish hippie
   strikes again). I was using pure Debian, then I upgraded entire system
   hardware and decided to use [78]LibraNet. I was so pleased with Libranet
   that I put it on my new-2-me laptop too. 

   This has been an interesting thread. Thanks for the responses. 

   One trick I learned about for KDE's Konsole is adding "%i %m -ls" to the
   Command stanza on the Execute tab (Properties). With this little tweak, the
   .rc  files  are  read  on  launch.  My  brother  added some very handy
   Debian-centric stuff that I'm lost without these days, and it's nice to be
   able to use Konsole with its tabbing capabilities. If I was a better person,
   I'd spend some time to learn what each of those little dewhickymobobs do!