Bug#675008: bash: should handle /etc/bashrc.d (or similar) for non-login interactive shell

[Mathieu Roy]

Package: bash
Version: 4.2-2
Severity: wishlist

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.



-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bash depends on:
ii base-files 6.7
ii dash 0.5.7-3
ii debianutils 4.3
ii libc6 2.13-32
ii libtinfo5 5.9-7

Versions of packages bash recommends:
ii bash-completion 1:1.99-3

Versions of packages bash suggests:
pn bash-doc <none>

-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
if [ -x /usr/lib/command-not-found -o -x /usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/bin/python /usr/lib/command-not-found -- "$1"
return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
/usr/bin/python /usr/share/command-not-found/command-not-found -- "$1"
return $?
else
printf "%s: command not found\n" "$1" >&2
return 127
fi
}
fi
[ -z "$ETC_BASHRC_SOURCED" ] && for i in /etc/bashrc.d/*.sh ; do if [ -r "$i" ]; then . $i; fi; done


-- no debconf information



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

[Anders Kaseorg]

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

[Laurent Bigonville]

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

[Richard van den Berg]

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

[Christoph Anton Mitterer]

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.