Re: profile.d [was Re: UMASK 002 or 022?]

[Brian Mays <brian@debian.org>]

Somebody (I have no idea who) wrote:

> > Is there a mechanism for individual packages to update /etc/profile?
> > For instance, it's a pest for each of your users, individually, to
> > have to update their path to include /usr/bin/mh for nmh.

Here you assume that *all* of your users are going to use MH (or nmh).
If that is not the case, then /usr/bin/mh should not appear in
everyone's path.  Pity the poor user who types "rmm" instead of "rm"
(there is only one extra letter between the two) and then wonders why a
"Mail" subdirectory suddenly has appeared under his home directory.

schizo@debian.org (Clint Adams) writes:

> No.  The sendfile package adds a line to /etc/profile and
> /etc/csh.login (but not for other shells).

Hmm ... That is a direct violation of section 4.7.3 of the policy
manual.  This is a bug.

Personally, I think that this part of the sendfile package was poorly
designed.  A better solution to the problem that this is trying to solve
-- namely, the problem of alerting the user of incoming files that he or
she has received while off-line -- is to send an email to the user
whenever a file is received (if not every time, then use a cron job to
check it once a day).  Not only does this solution stay away from
cluttering up the user's log-in sequence (a very good thing), it is more
general.  My solution does not require the user to log into a terminal
to receive the notification, and if the user's email is forwarded, it
does not require the user to log into the system at all.

> Instead of this, I'd like to see it install a file containing some
> sort of shell metalanguage that can then be used to generate the shell
> startup files.  Somewhat like the menu package.

I would be wary of such a mechanism.  This thread has already covered
the horrible stuff that this type of thing can lead to.

> And even if you don't want packages doing it, it's still a useful tool
> for the admin.

I could see this as a useful tool; however, I would prefer to keep it an
*optional* tool.

- Brian