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

Previous Next

Full log

Message #125 received at 78308 <at> debbugs.gnu.org (full text, mbox):

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: Re: [bug#78308] [PATCH v3 10/10] news: Add news entry for
 etc-bashrc-d-service-type.
Date: Tue, 20 May 2025 07:45:47 +0200

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

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

Previous Next

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