Allowing the configure_shell_profile function to make directories

[Frizzus]

Motivation

After installing Nix using the recommended method, I noticed that nix commands were not available in my shell.

Context

Similar to this issue i'm using Solus linux ( Solus-Budgie-Release-2025-01-26 ).
When configuring shells the configure_shell_profile() function will try to configure nix at several places :

• /etc/bashrc
• /etc/profile.d/nix.sh
• /etc/zshrc
• /etc/bash.bashrc
• /etc/zsh/zshrc

This has been added in the following commit by @abathur.
However, the code does not create directories if it's missing, it's assuming that /etc/ /etc/profile.d/ and /etc/zsh/ exists.

Unfortunately in Solus linux the /etc/profile.d/ directory does not exist.
It becomes a problem because solus linux's user .bashrc only source the /etc/profile file.

default ~/.bashrc

source /usr/share/defaults/etc/profile

The sourced file will source the /etc/profile.d/ directory if it exists.

/usr/share/defaults/etc/profile

if [ -d /usr/share/defaults/etc/profile.d ] ; then
    for script in /usr/share/defaults/etc/profile.d/*.sh; do
        if [ -r $script ] ; then
            source $script
        fi
    done
    unset script
fi

if [ -d /etc/profile.d ] ; then
    for script in /etc/profile.d/*.sh; do
        if [ -r $script ] ; then
            source $script
        fi
    done
    unset script
fi

So to set up the shell of solus linux's user, the install script must create at least the profile.d directory.

PS : I'm struggling to find a way to make test for this.
The test tool seems to automatically create /outputs/out/etc/profile.d before testing the install script.

[abathur]

Note that while did touch the function, the core behavior (only creating profile.d/nix.sh if the directory exists) dates back to at least 2921165

I may be imagining something that doesn't happen in the wild, but my (personal) sense of the reason not to create /etc/profile.d/ is that installers for other projects may do what we were already doing here--use the presence of this directory as a sign that the user's shell profiles are likely to bother sourcing scripts placed there.

Since the profile.d scripts are easier for the user to clean up later, some of these may just create the script there if the directory exists (and not add themselves to other profiles), so they may start misbehaving in the presence of a non-functional profile.d directory.

That said, I was readily able to find examples of other projects forcibly creating this directory. Not sure if @grahamc will recall his reasoning at the time.

[abathur]

Smaller thoughts:

• I am not sure if there's a cheap way to know the existing shell profiles support this short of creating the directory, placing a stub that does something testable (maybe exit with a specific status) and try launching the relevant shell(s) to see if it was loaded.
• Worth seeing if the detsys installer still does it the same way or if it creates the directory (if so, they may know if it is causing knock-on problems).
• This would likely require some careful updates to uninstall instructions (but no sense putting work into that until the idea/approach are validated).