[opensuse-packaging] usage of /etc/profile.d
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? Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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. /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 -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
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
Hello Andrei and Werner, 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.
That would have been wasier than expeted....but....
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.
So what is your recommendation for this? Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2020-03-23 14:45, Axel Braun wrote:
Am Montag, 23. März 2020, 14:32:03 CET schrieb Andrei Borzenkov:
using /etc/profile.d for the purpose of defining aliases sounds rather pointless.
So what is your recommendation for this?
For some purposes, I've turned away from using aliases and towards using little shell scripts in either '/usr/local/bin' or "$HOME/bin". If the alias didn't have arguments/options, then I sometimes just use a symlink, e.g. something like /usr/local/bin/g -> ../../bin/git. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello Andrej, 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 ... 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
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
On 2020/03/23 14:16:23 +0000, Michael Matz wrote:
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 .
Good point ... same for tcsh Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Hello Michael, thank you for the clarification. Got it now. Take care Dieter Am Montag, 23. März 2020, 15:16:23 CET schrieb Michael Matz:
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
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 23.03.20 um 15:16 schrieb Michael Matz:
[...] 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 .
So if we have /etc/profile and /etc/profile.d already, maybe it makes sense to have /etc/bash.bashrc and /etc/bash.bashrc.d? And while we are at it those files installed by packages that are not actually meant to be edited need to be moved to /usr. Ie what's in /etc is actually for the admin so those "PLEASE DO NOT CHANGE" headers and .local files can be removed. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2020/03/24 08:53:51 +0100, Ludwig Nussel wrote:
Am 23.03.20 um 15:16 schrieb Michael Matz:
[...] 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 .
So if we have /etc/profile and /etc/profile.d already, maybe it makes sense to have /etc/bash.bashrc and /etc/bash.bashrc.d?
And while we are at it those files installed by packages that are not actually meant to be edited need to be moved to /usr. Ie what's in /etc is actually for the admin so those "PLEASE DO NOT CHANGE" headers and .local files can be removed.
Then *every* shell has to be hacked to know about /usr/etc/ as well as to look for a local version below /etc/ ... Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Am 24.03.20 um 10:46 schrieb Dr. Werner Fink:
On 2020/03/24 08:53:51 +0100, Ludwig Nussel wrote:
Am 23.03.20 um 15:16 schrieb Michael Matz:
[...] 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 .
So if we have /etc/profile and /etc/profile.d already, maybe it makes sense to have /etc/bash.bashrc and /etc/bash.bashrc.d?
And while we are at it those files installed by packages that are not actually meant to be edited need to be moved to /usr. Ie what's in /etc is actually for the admin so those "PLEASE DO NOT CHANGE" headers and .local files can be removed.
Then *every* shell has to be hacked to know about /usr/etc/ as well as to look for a local version below /etc/ ...
Yes. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/24/20 8:16 PM, Dr. Werner Fink wrote:
On 2020/03/24 08:53:51 +0100, Ludwig Nussel wrote:
Am 23.03.20 um 15:16 schrieb Michael Matz:
[...] 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 .
So if we have /etc/profile and /etc/profile.d already, maybe it makes sense to have /etc/bash.bashrc and /etc/bash.bashrc.d?
And while we are at it those files installed by packages that are not actually meant to be edited need to be moved to /usr. Ie what's in /etc is actually for the admin so those "PLEASE DO NOT CHANGE" headers and .local files can be removed.
Then *every* shell has to be hacked to know about /usr/etc/ as well as to look for a local version below /etc/ ...
Well fish already ships all its distro / default config into /usr/share/fish and whats in /etc is only for sysadmins / users. Haven't decided if we will bother with /usr/etc as well but I suspect not. Having said that fish doesn't even try to be close to posix compliant. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2020-03-23 12:53, Axel Braun wrote:
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. ___________^^^^^^^^^^^^^^ That's right - they get source'd in by the shell. (I assume you knew that already.)
Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Montag, 23. März 2020, 12:53:01 CET schrieb Axel Braun:
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.
How advised you to do this?
So how is the procedure? create a new file myaddons.sh, write the above stuff into it and it gets processed/pulled-in automatically?
The only usable way to define your own aliases system-wide is with /etc/ bash.bashrc.local. You may want to have a look: https://build.opensuse.org/package/show/home:frispete:Tumbleweed/etc-LISA where I tried to implement a save way to deal with that situation. In short, add a calling stub to /etc/bash.bashrc.local with markers in %post and remove it again in %postun. From there, you have every freedom, you like. ;-) Cheers, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Freitag, 27. März 2020, 20:17:20 CET schrieb Hans-Peter Jansen:
Am Montag, 23. März 2020, 12:53:01 CET schrieb Axel Braun:
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.
How advised you to do this?
Quatsch: Who -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Freitag, 27. März 2020, 20:17:20 CET schrieb Hans-Peter Jansen:
Am Montag, 23. März 2020, 12:53:01 CET schrieb Axel Braun:
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.
How advised you to do this?
A package reviewer for factory
So how is the procedure? create a new file myaddons.sh, write the above stuff into it and it gets processed/pulled-in automatically?
The only usable way to define your own aliases system-wide is with /etc/ bash.bashrc.local.
You may want to have a look:
https://build.opensuse.org/package/show/home:frispete:Tumbleweed/etc-LISA
where I tried to implement a save way to deal with that situation.
In short, add a calling stub to /etc/bash.bashrc.local with markers in %post and remove it again in %postun.
From there, you have every freedom, you like. ;-)
from what I got from this thread, /etc/bash.bashrc.local is currently the only solution Cheers Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello Hans-Peter, clicking on the link you provided ends in an "500 - internal server error OOPS" is there an error in the link or could that be a temporary issue of the server as such - or is this link not publicly accessible? Thank you, best Dieter Jurzitza Am Freitag, 27. März 2020, 20:17:20 CET schrieb Hans-Peter Jansen:
Am Montag, 23. März 2020, 12:53:01 CET schrieb Axel Braun:
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.
How advised you to do this?
So how is the procedure? create a new file myaddons.sh, write the above stuff into it and it gets processed/pulled-in automatically?
The only usable way to define your own aliases system-wide is with /etc/ bash.bashrc.local.
You may want to have a look:
https://build.opensuse.org/package/show/home:frispete:Tumbleweed/etc-LISA
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
The whole OBS seems to be down. Am 27.03.20 um 22:22 schrieb Dr.-Ing. Dieter Jurzitza:
Hello Hans-Peter, clicking on the link you provided ends in an "500 - internal server error OOPS" is there an error in the link or could that be a temporary issue of the server as such - or is this link not publicly accessible? Thank you, best
Dieter Jurzitza
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Freitag, 27. März 2020, 22:22:53 CET schrieb Dr.-Ing. Dieter Jurzitza:
Hello Hans-Peter, clicking on the link you provided ends in an "500 - internal server error OOPS" is there an error in the link or could that be a temporary issue of the server as such - or is this link not publicly accessible? Thank you, best
Should be up again, but might require a OBS account... Stay healthy everybody, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello Peter, thank you, works now. Stay healthy, too, best Dieter Am Freitag, 27. März 2020, 22:53:22 CET schrieb Hans-Peter Jansen:
Am Freitag, 27. März 2020, 22:22:53 CET schrieb Dr.-Ing. Dieter Jurzitza:
Hello Hans-Peter, clicking on the link you provided ends in an "500 - internal server error
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (10)
-
Andrei Borzenkov -
Axel Braun -
Ben Greiner -
Bernhard Voelker -
Dr. Werner Fink -
Dr.-Ing. Dieter Jurzitza -
Hans-Peter Jansen -
Ludwig Nussel -
Michael Matz -
Simon Lees