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: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Sergey Trofimov <sarg <at> sarg.org.ru>
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 16:38:37 +0900

Hi Sergey,

Sergey Trofimov <sarg <at> sarg.org.ru> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>>>> * etc/news.scm (channel-news): New entry.
>>> [...]
>>>> + (entry (commit "XXX")
>>>> +        (title
>>>> +         (en "New services for /etc/profile.d and /etc/bashrc.d"))
>>>> +        (body
>>>> +         (en "Two new Shepherd services, @code{etc-profile-d-service-type} and
>>>> +@code{etc-bashrc-d-service-type}, can now be used to configure and extend your
>>>>
>>> these are not Shepherd services, right?
>>
>> At the core, they are, but they are wrapped with some sugar in Guix,
>>
>
> Could you please explain this bit? As I see these are just computed
> files that produce `profile.d` and `bashrc.d` unions which are then
> sourced by a piece of code placed in a well-known file. When I read
> "shepherd", I expect that the service is managed with "herd".

Ah, you are right!  Re-reading (info "(guix) Service Composition") made
that clear to me.  I always assumed services had to be sequenced by
Shepherd no matter the type, but it seems it is Guix System that is in
charge during the early boot here, when running the activation script,
IIUC.

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

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

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

-- 
Thanks,
Maxim

Previous Next

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