some kde folks and me had a discussion regarding
sourcing .<someshell>rc files by xsession. i'm the
pedant who is strictly against such hacks. :) the only
clean solution is a shell-independent setup at
logon-time - pam_env.
now the problem is, that this module is "somewhat"
limited. the most relevant request is obviously, that
it should source per-user config files - say
~/.environment. a less relevant request is the ability
to form somewhat more complex expressions like, maybe,
a primitive version of bash-like ${var<op>}
substitutions (think of ${var:-default}). also, i think
that /etc/environment should be made more powerfull the
same way and should replace /etc/security/pam_env.conf
at all.
Logged In: YES
user_id=1142
If somebody comes with patches or takes of maintainership,
it is ok, but else nobody has time for that.
Logged In: YES
user_id=202645
so why do you resolve it rejected instead of postponed?
or why do you resolve it at all instead of setting the priority to
1?
by closing it as rejected you as saying that you don't want
this in in the first place, and somebody looking for a task in
pam will certainly not look at it.