Re: Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent
> Tach Axel,
Ditto. :-)
> Axel Beckert wrote:
> > Hi Frank and Tim,
> >
> > Frank Terbeck wrote:
> >> Tim Booth wrote:
> >> > This is a request on behalf of Bio-Linux and the Debian Med
> >> > developers. The attached file shows the zshrc used on Bio-Linux, and
> >> > the part we'd really like to see in the standard zsh-common package is
> >> > support for a zprofile.d configuration directory[...]
> >>
> >> Is there a specific problem you'd like to address?
> >
> > I'd be curious about Tim's reason, too. I see, he (co-)maintains quite
> > a lot of packages in Debian, but nothing which strikes me as
> > zsh-related.
> >
> > Oh, and I'm glad we're having that discussion in a bug report! So I'm
> > not the only one who thought about such a feature! ;-) (SCNR)
Tim does not maintain zsh related packages but he maintains machines
suggesting zsh to its users (which should make you happy ;-)). He would
like to add the same comfort to his users as we try to establish for
bash users where we are attempting to use the following problem which
frequently hits the users of scientific users (in Tim's case
specifically biologist). The problem is that upstream of some scientific
software is using either generic names or names which are just given in
Debian and we are beaten by name conflicts.
While we perfectly know that the best way would be to convince upstream
to find a better name it is often the case that this request is ignored
and even if upstream is willing to do this scientists tend to be
conservative and use old versions or are refering to these versions in
their scripts. We somehow need to address this need to make Debian
acceptable in this user group.
My suggested solution was to install a binary with the original /
expected name to
/usr/lib/debian-med/bin
(in the case of Debian Med users) and prepend this path to all those
users who consider themselves users of Debian Med. For a first
implementation this can be done by droping a file .blends in the
users $HOME considering the string
debian-med
There are other potential ways to implement this but this seems to be
the less invasive way which does not break Joey Randomusers setup at all
and can be controled by a user without bothering the admin. A generic
template for any Blend is in Git[2]. If you substitute '#BLENDNAME#' by
'debian-med' (or 'debian-science' or any other Blend) you get what we
want to install into /etc/profile.d as debian-med.sh (or
debian-science.sh etc.)
Tim's point is now that while this is nice for bash users it does not
work for users of zsh (and other shells) while it would be cheap to
also support these with a similarly low effort.
> >> I'm not a big fan of these kitchen sink directories everybody and
> >> their dog gets to dump stuff into.
> >
> > I'm actually quite a big fan of them (otherwise I probably never would
> > have written Run::Parts[1]). They make packaging extensions, addons,
> > plugins, etc. way easier as there's no need to modify the
> > configuration files of other packages (which is forbidden by Debian's
> > Policy).
> >
> > [1] https://packages.qa.debian.org/libr/librun-parts-perl.html
> > https://metacpan.org/release/Run-Parts
> >
> > See e.g. /etc/apache2/*-enabled/, /etc/apt/apt.conf.d/ or
> > /etc/bash_completion.d/ for examples used successfully by many
> > packages. And I recently saw that /etc/apt/preferences.d/ is actively
> > used by apt-listbugs to hold packages with RC bugs via pinning.
>
> The bash_completions thing is only there because bash doesn't have sane
> autoloadable functions.
I have to say that I make use of /etc/profile.d on my own boxes since it
makes changes here quite modular and easily maintainable. I'd not call
it kitchen sink where "everybody and their dog gets to dump stuff into"
- at least I'd not address root with this attribute.
> With respect to shells, I usually find that applications, that need to
> inject code into a user's shell to be by and large mis-designed.
While I can understand your feeling about this I personally think "it
depends". I can find some apt-installed /etc/profile.d/*.sh files on
my box which are quite sensible. I'm for myself make use of some
/etc/profile.d/proxy.sh
containing "export http_proxy=..." to make sure that all users get a
valid proxy environment and I have other examples which I consider
definitely not mis-designed.
However, in the topic above I would agree that prepending a path to PATH
is a mis-design to some extend but as I wrote above just to cure another
mis-design (wrongly choosen names) we need to cope with.
> Something that *might* make sense is to source stuff from /etc/profile
> and “/etc/profile.d/” in POSIX-mode. See ¹, a mail about that from 2011.
> Nobody cared enough to reply; which I guess that tells you something
> about the urgency of the situation. ;-)
I'd not say that the problem is urgent. Its simply practical for the
users in question who probably lived with workarounds for years.
> But like the mails says, even if we did that, it's hard to decide what
> because it's not used for portable purposes alone. The bash completion
> thing is sourced from there, which other POSIX shells will have a major
> problem with.
Our actual implementation is pure POSIX. We could live with some other
solution for instance droping another file (symlink) into
/etc/zprofile.d
or whatever. I agree that it might be a certain risk to inject each
code available in /etc/profile.d.
> I think the situation is messy and I'd like to not get my hands dirty.
> This is, however, my personal opinion and does by no means reflect the
> opinion of the rest of Debian's zsh packaging team. :-)
>
>
> > Another nice example which would be much easier that way is the
> > planned packaging grml's zshrc. (Which is still on my TODO list.)
>
> Grml's zshrc could replace the existing configuration. It has everything
> Debian's zshrc has and just piles up on that.
IMHO a modular addition is better than a replacement.
> > As far as I know we already have /usr/share/zsh/vendor-functions and
> > /usr/share/zsh/vendor-completions (of which only the latter is used so
> > far), but that doesn't cover startup files like zshrc, zprofile,
> > zshenv, etc.
>
> Yeah, those are used for completely different purposes, though. And
> adding them comes at virtually no additional costs.
If you can suggest a solution for the name space pollution problem for
zsh which is more elegant than the suggested solution for bash I'm keen
on hearing this.
> To my understanding, stuff in /etc is considered a configuration file,
> that might have been changed or added by the user and can therefore not
> be removed by packages.
It is removed on "apt-get purge" if unchanged - so I see no problem to
remove it as package removal time. The design of the script is choosen
that way that it also will set PATH only if the according dir exists -
so the script also does no harm if it might remain but all packages
profiting from it are removed.
> I could see using checksums to gauge whether or
> not a file is still in mint condition. I don't know if that is being
> done by dpkg these days.
Have you tried dpkg --purge / apt-get purge ?
> > The common argument against .d directories with configuration snippets
> > so far seemed performance issues to me.
>
> My main issue with it is littering.
Strange. I would consider everything merged into one file as
confusingly littered. The modularisation IMHO serves as a kind of
documentation which I consider very practical.
> Performance is a true concern (my personal config file is split up into
> multiple files and it not even funny - I'm putting off merging it into
> one file again for a while now), though. Albeit not my primary one.
If we talk about performance of firing up a bash / zsh as *user* shell I
can not imagine that this is an issue. For performance critical stuff
dash should be used anyway.
Just my 2 (or more) cents
Andreas.
¹ http://lists.alioth.debian.org/pipermail/pkg-zsh-devel/2011-October/000248.html
[2] http://anonscm.debian.org/cgit/blends/blends.git/tree/templates/profile.sh
--
http://fam-tille.de
Reply to: