Subject: Re: [bug#78308] [PATCH v3 10/10] news: Add news entry for etc-bashrc-d-service-type.

From: Sergey Trofimov <[email-masked]>
Date: Tue, 20 May 2025 07:45:47 +0200

Hi Maxim,

Maxim Cournoyer <[email-masked]> 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".

> 
> so perhaps I can say just 'services' or 'Guix services'.

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