GNU bug report logs - #78308
[PATCH 0/9] VTE integration support / Shell startup files refactor

Previous Next

Full log

View this message in rfc822 format

From: Sergey Trofimov <sarg <at> sarg.org.ru>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Luis Guilherme Coelho <lgcoelho <at> disroot.org>, Rutherther <rutherther <at> ditigal.xyz>, 78308 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>, Florian Pelz <pelzflorian <at> pelzflorian.de>
Subject: [bug#78308] [PATCH v3 10/10] news: Add news entry for etc-bashrc-d-service-type.
Date: Tue, 20 May 2025 11:03:33 +0200

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

[...]
>>>> also, I wonder if `etc/profile` produced by `build-etc/profile` should
>>>> also source files in corresponing `etc/profile.d`. This would allow
>>>> packages install shell profile extensions and it would fix e.g.
>>>> https://issues.guix.gnu.org/44997
>>>
>>> That would be useful, but there's one issue I see, is that the Red
>>> Hat/Fedora have standardized on /etc/profile.d/ as the place to put any
>>> shell extension scripts, which are even sourced for example by
>>> /etc/bashrc, which is a bit odd to me: /etc/profile is for interactive
>>> login shells, and /etc/profile.d should logically follow, it seems.
>>>
>>> Having /etc/profile.d instead of /etc/bashrc.d also means that scripts
>>> placed there must be POSIX compliant or contain conditional guards for
>>> the specific Shell they target.
>>
>> It seems I've phrased it a bit vague. I was writing about `profile.d`
>> directories in any guix profile (be it `guix home`, `guix shell` or
>> whatever). What I propose is that `<...>/etc/profile` (produced by
>> `build-etc/profile` procedure) would include the snippet to source
>> `profile.d`. The snippet could find the dir relative to its own location
>> so that the very same code could be placed as in the global file
>> (/etc/profile) as in per-profile files.
>
> Thank you for clarifying what you meant.  So just rephrasing to make
> extra sure, what you would like to see is that every profile generated
> would have in their etc/profile generated file something sourcing its
> etc/profile.d/*.sh files, so that installing e.g. bash_completion in a
> profile would automatically have its etc/profile.d/bash_completion.sh
> file sourced, correct?

Exactly. Basically, install the "for i in /etc/profile.d/*.sh; do"
snippet adjusted to look for `profile.d` relative to current file.

>
> I'm not sure how useful that would be, because IIRC the
> $profile/etc/profile of a generated profile is only ever sourced:
>
> 1. When it appears at /etc/profile, e.g. mapped there within a
> container

... or is one of the default user profiles:

--8<---------------cut here---------------start------------->8---
# from /etc/profile

for profile in "$HOME/.guix-profile"        \
               "$HOME/.guix-home/profile"   \
               "$HOME/.config/guix/current"
do
  if [ -f "$profile/etc/profile" ]
  then
    # Load the user profile's settings.
    GUIX_PROFILE="$profile" ; \
    . "$profile/etc/profile"
  else
    # At least define this one so that basic things just work
    # when the user installs their first package.
    export PATH="$profile/bin:$PATH"
  fi
done
--8<---------------cut here---------------end--------------->8---

this alone is already helpful as it resolves the flatpak bug
granted, custom profiles are not sourced by `/etc/profile`, but then
it's a power-user territory and they'll sort it out themselves.

> 2. The shell is started as a login shell, e.g. 'bash --login'
> Note the --login requirement; which would not be in effect for example
> when entering a 'guix shell' (which spawns 'sh') by default.  The
> etc/profile could be sourced manually, of course, but that seems to
> defeat the purpose of having it there in the first place.
>

This is a tougher nut to crack, could be done separately. On a first
glance it seems logical that 'guix shell' would start login shells,
however this would lead to duplicated search paths as these would be set
when starting the container and then when sourcing /etc/profile inside.
It could be remedied with such steps:

- Extract mandatory search path variables (PATH=, MANPATH=, etc) to a
  separate file (e.g. profile.env).

- Prevent 'profile.env' files to be sourced twice:
  if [ "GUIX_PROFILE_<hash>_LOADED" -ne 1 ]; then
     export PATH=...
     ...
     GUIX_PROFILE_<hash>_LOADED=1
  fi

- 'guix/scripts/environment.scm' procedures should be adjusted to
  additionally set 'GUIX_PROFILE_<hash>_LOADED' env variable to avoid
  duplication of search paths

>
> Another idea would be to have /etc/bashrc source /etc/profile.d like
> done in Fedora; that's a bit odd and I don't like it much for reasons
> explained earlier, but it has the benefit of being compatible with the
> packages like flatpak and vte that install things under etc/profile.d to
> extend the non-login shells as well.

I also don't like this idea. Why would non-login shells run
`/etc/profile.d`? Aren't they launched in environment where login
happened and therefore `/etc/profile` got applied already?

> That could be made to work automatically for the fixed location like
> /run/current-system/profile/etc/profile.d for system-installed
> packages as well as $HOME/.profile/etc/profile.d/, and even for
> non-containerized environments via $GUIX_ENVIRONMENT/etc/profile.d/.
> It wouldn't work in containerized environment; this would need adding
> a /etc/bashrc inside the container that would source
> $GUIX_ENVIROMNENT/etc/profile.d.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.