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 to mirror /etc/profile.d which is read by BASH and allows
packages to drop config fragments into the shell profile.

In Bio-Linux this is hooked from zshrc but actually a modified zprofile
probably makes more sense.

This is pretty trivial to implement, as far as I can see.  What do you think?

Cheers,

TIM

Frank Terbeck wrote:
[...]

Well, since zsh's default behaviour is to error out with non-matching
globs, using the qualifier is actually required:

for i in /etc/zsh/zshrc.d/*.zsh(N); do

Hey Tim,

Tim Booth wrote:
[...]

Is there a specific problem you'd like to address? I'm not a big fan of
these kitchen sink directories everybody and their dog gets to dump
stuff into. Especially in “/etc” since it's kind of hard for a package
to remove stuff from there again.
[...]

Ungh... Don't do it like this! Just use globbing to create a list of
files. The idea about "null_glob" is sound in itself (even though in zsh
solvable differently, using the "N" glob qualifier). But since you do
this test in the loop:

you don't need null_glob at all. Thus, I'd do this:

for i in /etc/zsh/zshrc.d/*.zsh; do
    # I'm quoting the parameter, because someone might have
    # set the SH_WORD_SPLIT option in, say "~/.zshenv".
    if [ -r "$i" ]; then
        source "$i"
    fi
done


Regards, Frank

Hi Frank and Tim,

Frank Terbeck wrote:

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)

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.

Another nice example which would be much easier that way is the
planned packaging grml's zshrc. (Which is still on my TODO list.)

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.

Huh? I'm sorry, but I have no idea what kind of issues you might refer
to. If it's a "conffile" coming from a package, dpkg handles that
well. If it's a generated file there's ucf to properly handle it. So
I'd be happy if you could elaborate that issue a little bit as I'd be
curious to learn about issues I'm not yet aware of.

The common argument against .d directories with configuration snippets
so far seemed performance issues to me.

		Regards, Axel

Tach Axel,

Axel Beckert wrote:

I actually though that this had been discussed before, but I couldn't
find a previous discussion. The instance I was recalling was a about
sourcing stuff from /etc/profile and /etc/profile.d/ itself (see below).

The bash_completions thing is only there because bash doesn't have sane
autoloadable functions. The apache directories I find rediculously
messy.

The apt-usecase seems legit.

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.

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. ;-)

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.

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. :-)

Grml's zshrc could replace the existing configuration. It has everything
Debian's zshrc has and just piles up on that.

Yeah, those are used for completely different purposes, though. And
adding them comes at virtually no additional costs.

(*puts on grml-zshrc hat*) As I recall, with grml's zsh configuration,
we had a ton of stuff in /etc/zsh/... and for some reason (I'm not
familiar with any particulars in the developer reference), we couldn't
just remove them in a maintainer script.

It was a huge pain in the ass and for quite a while we had code in the
setup that checked for the existence of old files in those directories,
asking the user to consider removing them. (*puts off hat again*)

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.  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.

My main issue with it is littering.

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.


Regards, Frank

¹ http://lists.alioth.debian.org/pipermail/pkg-zsh-devel/2011-October/000248.html

Ditto. :-)

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 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.

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.

I'd not say that the problem is urgent.  Its simply practical for the
users in question who probably lived with workarounds for years.

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.

IMHO a modular addition is better than a replacement.

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.

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.

Have you tried dpkg --purge / apt-get purge ?

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.

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

Hello Frank,

I’d like to vote for exactly that; sourcing “/etc/profile” in POSIX-mode seems
very valid. This file currently seems POSIX without Bashism, and I propose to
keep it POSIX.

I’m not familiar with other shells, but I don’t think Zsh in POSIX mode provides
the “$BASH” variable, so the Bash guard in “/etc/profile” should prevent it from
breaking Zsh.

Regards,
Franklin

Hi Tim,

About your original request: I don’t think “/etc/zsh/zprofile.d” is going to
help. There is some distinction between x-profile and x-rc: profile are supposed
to be read only for the login shell, once (in every session). We put environment
variable there, for all the child processes to inherit. In contrast, x-rc files
should be read for all interactive invocation of shells; if I’m in an
interactive Zsh session, and I type “zsh”, this child shell reads the zshrc
again.

Whether we want to modify the path in zprofile or zshrc, depends on where you
want the change to take place. Generally I would update $PATH in
“/etc/profile.d/”, so that GUI applications like IDEs can find them (think of
PyCharm finding your Python); however, from your description, the users of your
package seem to expect the CLI tools to only be available in their interactive
shells (like Bash and Zsh). If that’s the case, then I think what you want is
actually “/etc/zsh/zshrc.d”. For example, I’m using GNOME Shell, and my terminal
emulators might are not creating “login shells” (because the actual login shell
is GNOME Shell in this case), so these Zsh sessions don’t read my “~/.zprofile”
at all.

Regards,
Franklin

Hi,

I had a bug report on my package:

The discussion had reference to this bug here

Let me share my thought here too ...

In very good old days, as long as you keep your root and daemon's account in the
default shell (bash?), you didn't have much problem with chsh on user account.  I am
sure people use to use csh this way.  Even then, there were some advocacy to use
ksh/bash compatible shell, I suppose, to ensure proper and successful environment
variables setteing or something :-)

Once people started using X, choosing csh as the login shell via chsh became non-
option.  But people had false sense that the traditional chsh mechanism is right way
to change login shell among bash/zsh (or POSIX shells).

Making Xsession.d scripts bash/zsh compatible caused several bugs and their fixes in
my im-config package which is a thin glue layer to choose i18n GUI keyboard input
mechanism offered by one of several input module frameworks (ibus, fcitx, uim, SCIM,
...).

I think the root cause of the problem is we choose to parse these system startup
scripts with the shell chosen effectively by chsh command for interactive shell.  I
mean shell set in /etc/passwd.

Before X, as long as we don't change login shell for the root and other daemon
program's accounts from bash, we had no problem.

With X, we started to say POSIX shell (no csh) should be chosen by chsh.

Now we are facing another problem with Wayland and how shell use their startup code.

To me, non-interactive shell used by Xsession or and other system configuration
should be separately configurable from whatever interactive shell user desired to use
in /etc/passwd. /usr/bin/sh should be the one for non-interactive shell but if it is
difficult initially, I can live with /uar/bin/bash instead.

Until someone with lots of energy and (social and technical) skill decides to work on
separating these 2 shells on Debian system, I strongly recommend people to set so-
called "login shell" always to /usr/bin/bash.

If you want to use other shells (zsh, csh, fish, ...) for INTERACTIVE use, the
easiest solution is to set it in your terminal program.  Then there is no
COMPATIBILITY nor PISIX problem.

If you want to use non-bash for SSHed host, I suppose, adding something along the
following in ~/.baahrc should be able to set INTERACTIVE login shell to non-bash
ones.
---
# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

exec /usr/bin/zsh -i
---

....

It would be great, if chsh is made to control interactive shell.

Until we sort out separation of "non-interactive system configuration shell" and
"interactive console shell", there will be bugs caused by the differences even among
so-called accepted shells (POSIX).  I don't think adding work around will never solve
this bug prone situation.

This will involve some coordination with systemd/pam things, I don't have high hope
and motivation.  If anyone does, I will be happy.  Until then, all I can say is chsh
is a historic tool which has no practical use.  Just use basj and use practical
solution I mentioned above.

Good luck.


Osamu

Hi,

I had a bug report on my package:

The discussion had reference to this bug here

Let me share my thought here too ...

In very good old days, as long as you keep your root and daemon's account in the
default shell (bash?), you didn't have much problem with chsh on user account.  I am
sure people use to use csh this way.  Even then, there were some advocacy to use
ksh/bash compatible shell, I suppose, to ensure proper and successful environment
variables setteing or something :-)

Once people started using X, choosing csh as the login shell via chsh became non-
option.  But people had false sense that the traditional chsh mechanism is right way
to change login shell among bash/zsh (or POSIX shells).

Making Xsession.d scripts bash/zsh compatible caused several bugs and their fixes in
my im-config package which is a thin glue layer to choose i18n GUI keyboard input
mechanism offered by one of several input module frameworks (ibus, fcitx, uim, SCIM,
...).

I think the root cause of the problem is we choose to parse these system startup
scripts with the shell chosen effectively by chsh command for interactive shell.  I
mean shell set in /etc/passwd.

Before X, as long as we don't change login shell for the root and other daemon
program's accounts from bash, we had no problem.

With X, we started to say POSIX shell (no csh) should be chosen by chsh.

Now we are facing another problem with Wayland and how shell use their startup code.

To me, non-interactive shell used by Xsession or and other system configuration
should be separately configurable from whatever interactive shell user desired to use
in /etc/passwd. /usr/bin/sh should be the one for non-interactive shell but if it is
difficult initially, I can live with /uar/bin/bash instead.

Until someone with lots of energy and (social and technical) skill decides to work on
separating these 2 shells on Debian system, I strongly recommend people to set so-
called "login shell" always to /usr/bin/bash.

If you want to use other shells (zsh, csh, fish, ...) for INTERACTIVE use, the
easiest solution is to set it in your terminal program.  Then there is no
COMPATIBILITY nor PISIX problem.

If you want to use non-bash for SSHed host, I suppose, adding something along the
following in ~/.baahrc should be able to set INTERACTIVE login shell to non-bash
ones.
---
# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

exec /usr/bin/zsh -i
---

....

It would be great, if chsh is made to control interactive shell.

Until we sort out separation of "non-interactive system configuration shell" and
"interactive console shell", there will be bugs caused by the differences even among
so-called accepted shells (POSIX).  I don't think adding work around will never solve
this bug prone situation.

This will involve some coordination with systemd/pam things, I don't have high hope
and motivation.  If anyone does, I will be happy.  Until then, all I can say is chsh
is a historic tool which has no practical use.  Just use basj and use practical
solution I mentioned above.

Good luck.


Osamu