The Answer Gang

By Jim Dennis, Karl-Heinz Herrmann, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!

---

Cannot talk using "talk"

unless we tell it to?

From Jaye Inabnit ke6sls

Answered By: Thomas Adam, Benjamin Okopnik, Kapil Hari Paranjape

Hey guys:

I'm just getting 'round to reading this months Gazette. Anyway, about the 'talk' and 'talkd' issue, make sure you also mention that probably every distribution these days disables 'messages', which means that users wouldn't even be notified that someone is trying to 'talk' with them. Check it with an xterm or in console:

[Thomas] Actually, it is the default for it to be on, for any Linux system that I have come across, but I am not going to argue the point.

jaye@librabogus:~$ mesg
is y
jaye@librabogus:~$

The way I fixed this issue was to modify my global preference file '/etc/profile' (within Debian systems):

EDITOR=/usr/bin/vim
PAGER=/usr/bin/less

umask 002

mesg y

[Thomas] Adding it to /etc/profile is not something I would do - it should not be a system-wide policy - making it a local user issue is a better idea. Leave your poor users alone.

[Ben] WHOOPS. As Thomas has already pointed out, this is a very poor practice in most cases. There's not much wrong with setting the PAGER to "less", but making "vim" the default editor means that new users can get horribly confused by an unresponsive beeping application that they don't know how to exit. Worse yet, setting the umask to 002 sets up a security risk every time a user creates a file - one of which they will usually be unaware. These things should not be set by policy (i.e., in /etc/profile) but via an informed, per-user decision; that's why individual .profile 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 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 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!

---

This page edited and maintained by the Editors of Linux Gazette
HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

---