Re: /etc/profile.d
Paul Seelig <pseelig@mail.uni-mainz.de> wrote:
>> So if you know that the policy forbids profile.d, why do you start
>> this discussion here?
> No, the policy doesn't forbid such a directory in itself. It just
> forbids that such a directory be a default Debian system component
> like it is in Redhat. And our policy is right on this.
You're right, I should differentiate more in this point.
> It doesn't prohibit the inclusion of such a directory as an *add-on*
> mechanism provided by a separate optional package.
That's correct. You only have to make sure that no Debian package
depends on this mechanism.
> And that's just the way to go. Such a mechanism is just too damn
> useful for sysadmins to be neglected. I've made such a package which
> implements such an add-on mechanism and have made it available
> including sources under
> "ftp://ntama.uni-mainz.de/pub/debian/unofficial/sysprofile/";. It is
> still far from perfect, is only useful for bash and i lack the time
> to work further on it. So if someone would like to take a look at
> it...
> Another option is Massimo dal Zotto's "shellrc" package available from
> "http://www.cs.unitn.it/~dz/debian/";. It supports csh and bash.
But if you really need such a mechanism, why don't you create a real
generic one? If I would need something like this, I would go the
following way:
- Define a generic configuration file format, with a very restricted
syntax, which supports the following constructs:
a) setting environment variables
b) executing external binaries
c) defining aliases (maybe restricted to aliases without parameters)
- For every shell write a parser, which reads in all these shell
independent files and creates one startup script for every shell.
- Write a update-menu like mechanism, which runs all these parsers
after one of the shell independent files was added/removed/changed.
Such a concept can be implemented in a fully shell independent way and
if some shell doesn't support a global configuration file, it may be
possible to create a little wrapper, which starts /bin/sh with its
generated profile and then exec the selected shell (this works at
least for a) and b), and maybe we should completely drop c)).
Such a solution is shell independent and keeps the administration
overhead minimal, because administrator doesn't have to know the
syntax of every shell (including all incompatibilities which aren't
allowed in /etc/profile by some more or less sh compatible shell), but
you only need to know the minimal syntax of the shell independent
config files. And it doesn't slow down the startup of the shell by
converting /etc/environment or converting "export FOO=bar" to
"setenv FOO bar" at boot time using sed or other external tools at
shell startup time.
So if someone really needs something like /etc/profile.d, the above
idea could be a portable way to implement this.
Tschoeeee
Roland
--
* roland@spinnaker.de * http://www.spinnaker.de/ *
Reply to: