Bug#675008: bash should source package hooks into interractive shells

[Patrick Schleizer]

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

> https://bugs.linuxfoundation.org/show_bug.cgi?id=1367
> 
> --- Comment #1 from Jeff Licquia  ---

> In general, LSB and FHS don't mind if someone like Debian wants to
> implement something like this.  We particularly don't want to be the
> "gatekeepers of innovation" in any way.  So if you're asking for our
> blessing to do this, you have it.

> [...]

> First, are other distros on board with something like this?  Or do
> they already support such a thing?
>
> [...]

Matthias Klose:
> 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, 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.

Bug#675008: bash should source package hooks into interractive shells

[Matthias Klose]

Am 07.05.2014 13:19, schrieb Dimitri John Ledkov:
 
 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.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675008: bash should source package hooks into interractive shells

[Dimitri John Ledkov]

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.

From 04d2895125d9748b5d19f42ec83d3896d635 Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov dimitri.led...@canonical.com
Date: Wed, 7 May 2014 11:52:31 +0100
Subject: [PATCH] Non-maintainer upload.

* Non-maintainer upload.
* Source profile.d from /etc/bash.bashrc to allow packages ship
  integration hooks into interactive shells, same ones they already ship
  for login shells. (Closes: #675008)
---
 debian/changelog   |  9 +
 debian/etc.bash.bashrc | 22 ++
 2 files changed, 31 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index ccda677..6bc7729 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+bash (4.3-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Source profile.d from /etc/bash.bashrc to allow packages ship
+integration hooks into interactive shells, same ones they already ship
+for login shells. (Closes: #675008)
+
+ -- Dimitri John Ledkov x...@ubuntu.com  Wed, 07 May 2014 10:50:11 +0100
+
 bash (4.3-7) unstable; urgency=medium
 
   * Apply upstream patches 009 - 011 (replacing local patches):
diff --git a/debian/etc.bash.bashrc b/debian/etc.bash.bashrc
index 54687b1..e38b202 100644
--- a/debian/etc.bash.bashrc
+++ b/debian/etc.bash.bashrc
@@ -53,3 +53,25 @@ if [ -x /usr/lib/command-not-found -o -x /usr/share/command-not-found/command-no
 		fi
 	}
 fi
+
+# Source profile.d even though it's meant to be for login shells
+# only, because we need a hook integration for
+# e.g. command-not-found, bash-completion, gnome-terminal/vte,
+# screen/byobu etc. And e.g. on fedora systems, bashrc does source
+# profile.d. If something does break, things in /etc/profile.d will
+# need to differentiate interractive shells by inspecting $PS1 (or
+# similar as /etc/profile.d/vte.sh already does). If there is bad
+# interraction between snippets in profile.d, that's already a bug,
+# against affected packages to sort out, since login shells are
+# already affected.
+#
+# Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008
+
+if [ -d /etc/profile.d ]; then
+  for i in /etc/profile.d/*.sh; do
+if [ -r $i ]; then
+  . $i
+fi
+  done
+  unset i
+fi
-- 
2.0.0.rc0


Regards,

Dimitri.