Hello, On Mon, 23 Mar 2020, Dr.-Ing. Dieter Jurzitza wrote:
what are you meaning with "child process"? If a terminal (say xterm ..) is started within the gui, all the bash - related aliases within /etc/profile.d/ are processed and active (i. e. ls.bash ...) so how comes you assume the usage of this directory to be "pointless"? I do not get you there ...
ls.bash is _always_ sourced, no matter if interactive login shell or not (see /etc/bash.bashrc). Some other files as well (/etc/profile.d/alias.bash and ~/.alias). But generally, files within /etc/profile.d are not sourced by an interactive shell that isn't also a login shell. You should see that when you try the suggestion: put some random alias into /etc/profile.d/bla.sh and try it out. You will find that the new alias won't exist, except for a 'bash --login' after you have _unset_ $PROFILEREAD. Right now /etc/bash.bashrc.local is the only place where you can put system-wide aliases that shouldn't be overwritten by packages. Werner: ideally you would devise some file (or directory) names where people could put it their system-wide aliases, also from packages, that would be sourced from /etc/profile.d/alias.bash . Ciao, Michael.
Best
Dieter
Am Montag, 23. März 2020, 14:32:03 CET schrieb Andrei Borzenkov:
23.03.2020 15:18, Dr. Werner Fink пишет:
On 2020/03/23 12:53:01 +0100, Axel Braun wrote:
Hi,
I used to write some alias into /etc/bash.bashrc.local :
%pre #Write environment changes to /etc/bash.bashrc.local cat > /etc/bash.bashrc.local << "EOF" alias cdutil='cd /usr/bin' #(and some more...) EOF
Now I was advised to use /etc/profile.d instead. This directory contains a bunch of non-executable files ending on sh, .csh, .ssh etc.
So how is the procedure? create a new file myaddons.sh, write the above stuff into it and it gets processed/pulled-in automatically?
Add your myaddons.sh and if possible (that is test it out in tcsh!!!) a myaddons.csh with your alias to the file list of your package.
Given, that
1. aliases cannot be exported, so even though /etc/profile(.d) is processed by GUI session startup script, aliases that are defined there are never seen by any child process
2. shells started in GUI session are usually started as non-login shell and so do not process /etc/profile(.d)
3. even if shell is started as login shell, SUSE guards /etc/profile(.d) against multiple processing by exporting PROFILEREAD which gets exported during session startup, so /etc/profile(.d) in any login subshell is not processed either
using /etc/profile.d for the purpose of defining aliases sounds rather pointless.
/etc/bash.bashrc.local is the the local admin only to avoid changes on the main part /etc/bash.bashrc as this will be overwritten with next update