As described at http://yeupou.wordpress.com/2012/05/29/having-homemade-aliases-functions-and-such-available-to-every-interactive-shells/  I find frustrating to be unable by default to add local shell aliases/functions to be automatically sourced for any interactive bash shell.

This mechanism exists for *login* interactive shells (/etc/profile.d) and is actually even used by bash-completion. I found no conclusive reason not to provide similar possibility for non-login shells that are probably the most common on a X session through xterms.

Reading bug #275623, I doubt that any change in this regard will occurs on base-files.

I think it would be really nice to be forced to edit by hand /etc/bash.bashrc to achieve the simple addition of local functions/aliases/etc.
It's a no-go to edit /etc/skel/, as far I understand that won't make for site-wide functions/aliases but copied-once files that will easily get outdated.
It's also a no-go to botch /etc/profile supposed behavior (run-once at login only) to get it called by /etc/bash.bashrc.

Hi,

I'm interested in this feature as well (so hopefully bash-completion can
replace its /etc/profile.d/bash_completion.sh with an
/etc/bash.bashrc.d/bash_completion.sh to really work out of the box, see
#678174).

So, I created a patch. It isn't very complicated (pretty much copied the
lines for /etc/profile.d from /etc/profile), but I've tested this and it
works.

I'm not sure what is the best place to document this (if any). If you
have suggestions, I'd be happy to also patch the documentation.

Gr.

Matthijs

=== modified file 'etc.bash.bashrc'
--- etc.bash.bashrc     2011-11-30 11:27:55 +0000
+++ etc.bash.bashrc     2012-06-20 15:32:58 +0000
@@ -49,3 +49,13 @@
                fi
        }
 fi
+
+
+if [ -d /etc/bash.bashrc.d ]; then
+  for i in /etc/bash.bashrc.d/*.sh; do
+    if [ -r $i ]; then
+      . $i
+    fi
+  done
+  unset i
+fi

=== modified file 'rules'
--- rules       2011-11-30 09:09:57 +0000
+++ rules       2012-06-20 15:32:57 +0000
@@ -195,6 +195,7 @@
        dh_installdirs -p$(p) \
                bin \
                etc/skel \
+               etc/bash.bashrc.d \
                usr/share/doc/$(p)
        dh_installdirs -p$(p_doc) \
                usr/share/doc/$(p)

block 678174 by 675008
thanks

This is required for fixing http://bugs.debian.org/678174
“bash-completion: /etc/profile.d/bash_completion.sh does not work for
non-login shells (e.g., screen, xterm)”.

It’s also something we needed in the MIT Debathena project.  We currently
work around this by ‘dpkg-divert’ing /etc/bash.bashrc, which is horrible.

Anders

Dear Maintainer,

I've been using the patch from message 5 (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008#5 ). It works
well. This is a useful feature. Please review and merge.

Cheers,
adrelanos

Dear maintainer,

is there a chance that we can get a pendant to /etc/profile.d but for non-login
interactive shells in time for the next stable release? Patches are already
suggested in this bug report and it is currently blocking some other bugs which
could get easily fixed if they were applied.

Thanks!

 - Fabian

Hey.

Anything new here? This is nearly two years old now,... it blocks
several other really annoying bugs,.. a fix seems quite simple and a
patch was even provided.
What keeps it from being merged?

Cheers,
Chris.

Hi,

Christoph Anton Mitterer wrote (04 Apr 2014 01:53:38 GMT) :

I would suggest:

  1. Make the patch complete, so that it can actually be applied.
     (My understanding is that the proposed patch does not update
     the documentation, and Matthijs offered to do it at some point.)

  2. Tag this bug report "patch".

  3. Ping the maintainer again.

(Just my 2 cents.)

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

Hello all,

I'm proposing below patch, which sources profile.d hooks into the
interactive shells from /etc/bash.bashrc.

First of all, there is no reason to create a distinct /etc/bashrc.d,
since hooks can trivially inspect and figure out if they are sourced by
login or interactive shells (as vte.sh already does).

If there is bad interaction between hooks, well, that's already a bug in
those hooks under login shells.

Matthias and I, disagree on whether login & interractive shell
environments should be different or similar. I side, that the two should
be similar. Furthermore, looking at some of the existing hooks, I didn't
see any that would negatively affect interractive shells and/or where
for any reasons undesirable under interractive shells.

Below change is also in-line with what other distributions are doing,
e.g. fedora 20 is sourcing profile.d from their system-wide bashrc.

Everyone affected please test below patch, to see if it satisfies your
needs and unblocks shipping interractive shell hooks. I intend to NMU
this patch into delayed/10 on Friday, unless it is found buggy and/or
unacceptable, or maintainer chooses to fix this bug report using below
patch or any other means.

Am 07.05.2014 13:19, schrieb Dimitri John Ledkov:

I don't think this is the correct solution, so please don't NMU. I think it is
wrong to piggy back on the /etc/profile.d mechanism, which was introduced by the
LSB. Also mixing profile and bashrc stuff seems to be wrong.

Citing implementations in other distributions doesn't help much, these may
change without notice. So the best thing would be to bring such a proposal to
the LSB, or to FreeDesktop, and then implement that one after it is accepted.

  Matthias

Hey Matthias.

So if you think that a working solution, which is used by others, isn't
the correct one... what is you suggestion how to do it? ;-)

I mean this bug, blocking so many things, shouldn't just left open till
the end of days.

Cheers,
Chris.

Christoph Anton Mitterer:
isn't the correct one... what is you suggestion how to do it? ;-)

I am a afraid, I believe he already answered that above.
FreeDesktop, and then implement that one after it is accepted.

Would you be up to do that?

Cheers,
Patrick

Posted an LSB feature request:

define bash non-login shell snippet drop-in folder /etc/bash.bashrc.d/
in LSB

https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=4167

Cheers,
Patrick

Patrick Schleizer:

Mats Wichmann:
only a POSIX shell.

Therefore, posted a FHS feature request:

'define bash non-login shell snippet drop-in folder /etc/bash.bashrc.d/
in FHS' [2]

Cheers,
Patrick

[1] https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=4167#c2
[2] https://bugs.linuxfoundation.org/show_bug.cgi?id=1367

I don't think this LSB / FHS approach is appropriate here. I appreciate
having got a very reasonable response from LSB / FHS.

Matthias Klose:

Matthias, having quoted the above, I do not think this is how it works.
LSB / FHS are not, and do not want to be the gatekeepers of innovation.
As I understand, they neither desire, expect nor encourage innovations
such as this to go through them. Rather, Debian and/or Fedora etc.
innovate something and it may be standardized then.

[And as a personal remark, I am glad it is that way, that there is no
bureaucratic authority above Debian that hinders innovation.]

So in conclusion, please do no let this LSB / FHS approach block this
ticket.

Hello,

More and more packages are adding files to /etc/profile.d/ but nothing
is sourcing them by default in debian.

$ apt-file search /etc/profile.d/|wc -l
23

Other distributions (RH-like) are sourcing files put in that directory
for years now (but not /etc/profile itself)

 From /etc/bashrc:

     # Only display echos from profile.d scripts if we are no login shell
     # and interactive - otherwise just process them to set envvars
     for i in /etc/profile.d/*.sh; do
         if [ -r "$i" ]; then
             if [ "$PS1" ]; then
                 . "$i"
             else
                 . "$i" >/dev/null
             fi
         fi
     done

Wouldn't it make sense to follow what RH and already some packages in
the archive are doing and source .sh files from /etc/profile.d/ in
non-login shell as well?

Kind regards,

Laurent Bigonville

I just had to resort to modifying /etc/bash.bashrc which is really ugly IMHO.

Is there anything I can do to make this functionality sane in Debian?

Kind regards,

Richard van den Berg

Hello,

Would anything eventually be done for this?

The default experience for gnome-terminal users is not good as nothing
is sourcing /etc/profile.d/vte-2.91.sh for non-login interactive shells,
meaning that the CWD is not set properly when opening new windows or tabs.

Being able to source snippets is a desirable feature in any cases, other
distributions have gone the way of using /etc/profile.d/ and some (27)
packages are already shipping files there in debian.

So either debian/we come with something better (and preferably
compatible with other distributions) or we also go the way of sourcing
/etc/profile.d/ for non-login interactive shell.

Kind regards,

Laurent Bigonville

Le 10/03/20 à 18:37, Laurent Bigonville a écrit :

Actually the inheritance of the cwd in gnome-terminal is working fine as
we have a custom patch for it that we carry since 2015, I don't think
that others have

Hey.

Anything new on this? :D

It's probably not that important anymore nowadays... VTE works without
it's shell file being sourced[0], but still:

Most files in /etc/profile.d/ seems to actually rather belong to bash
and interactive shells (and thus rather the .bashrc family than the
.profile family).

I also don't think anything will come forward from LSB or freedesktop
side - and to me, it also doesn't seem to be their business.

.bashrc-like files are quite clearly bash's domain (unlike .profile
which is shared by several sh-like shells), so if at all it would be
bash's duty to "standardise" this.


So are there still any technical reasons against shipping a
/etc/bash.bashrc.d/ (and inviting other packages to use that)?

Perhaps I wouldn't even source it from /etc/bash.bashrc but leave that
up to the user's .bashrc.

But at least it would be a better place for these shell snippets than
/etc/profile.d.



Cheers,
Chris.


[0] Well the behaviour is actually still a bit different, cause the
shell script uses the terminal's OSC 7 command (which IMO has anyway
some minor/subtle security issue), e.g. it would pick up the path for
sub-shells/screens/etc. running in the terminal.

Matthias,

Are you willing to apply your Ubuntu fix from
https://launchpad.net/ubuntu/+source/bash/5.2.37-2ubuntu4 to Debian
for inclusion in trixie?

It looks like it doesn't fully fix the issues people complained about
here in https://bugs.debian.org/675008 but it does at least
significantly improve the out-of-the box functionality for vte
terminal apps including but not limited to gnome-console, ptyxis, and
tilix. It also allows dropping the workaround patch
(Provide-fallback-for-reading-current-directory-if-OS.patch) from
gnome-terminal.

I'm thinking that we could then close 675008 and people whose needs
are not met by this fix could open individual separate bugs since it
seems like you want to handle things on a case-by-case basis as you're
explicitly sourcing the vte script instead of everything in a
specified directory.

If it helps, I could file an unblock bug for the vte change, but I
don't understand the significance of the color prompt update.

Thank you,
Jeremy Bícha

This has been fixed for VTE apps in bash 5.3-1.

I asked in July and Matthias was reluctant to backport this fix to Debian 13.

Thank you,
Jeremy Bícha