Is this even necessary? Shouldn’t Tumbleweed access libaries and executable files in subfolders of “/opt” by default?
Also I am not sure how exactly to add to “/etc/profile.local”…
Do I need the “export” command like in “.bashrc”?
or just the “PATH=xyz” designation?
As it is now the application I try to install (invokeai) doesn’t seem to find the ROCm libs and “code objects”… - but this might have other reasons - I am in the process of troubleshooting here at the moment…
(I am well aware that ROCm will be hit and miss in it’s current state!
But here that’s not my point - here I try to learn about the recommended way to configure basic stuff in Tumbleweed…)
@jhhh Hi, nope it needs to be added, for the libraries etc the install should put a conf file in /etc/ld.so.conf.d/ for the system to know where external libraries are and run ldconfig to update the cache.
Yes, ‘/etc/profile.local’ is the correct place but, the only documentation is in the openSUSE ‘/etc/profile’ file itself –
# PLEASE DO NOT CHANGE /etc/profile. There are chances that your changes
# will be lost during system upgrades. Instead use /etc/profile.local for
# your local settings, favourite global aliases, VISUAL and EDITOR
# variables, etc ...
Yet another reason for not editing system configuration files placed in ‘/etc’ by the distribution …
Please be aware of the related Bash man page entries –
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it
first reads and executes commands from the file /etc/profile, if that file exists. After reading that file,
it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands
from the first one that exists and is readable. The --noprofile option may be used when the shell is started
to inhibit this behavior. Please note that the file /etc/profile includes an autodetection shell code wether
it has to source /etc/bash.bashrc as well as ~/.bashrc.
Your question related to paths being exported at system boot time is possibly answered as follows:
Paths defined by entries in “Profile” files are not exported at boot time.
The file is called at user login and, the Path is exported at that point in time to the user’s session.
Yes, there is a systemd “paths.target” and, there are “systemd.path” units but, that’s a systemd specific issue which is only related to the boot process as such …
From “UNIX® for the Impatient” – Paul W. Abrahams and Bruce A. Larson – published by Addison-Wesley:
2.6.5 Environment Variables
Each process has a set of environment variables associated with it.
2.9.2 The PATH Environment Variable
Programs and other executable files can reside in many different directories. UNIX® therefore provides a search path for executable files so that you don’t need to remember (and type) the pathname of each command that you execute. The search path is recorded in the environment variable PATH which you can examine by typing
Yes, yes, I know, there is an awful amount of material which proclaims that, there’s another explanation of what a “Path” is – in other operating systems – which are usually not related to UNIX®.
Strangely, there doesn’t seem to be a Linux Standards definition of the PATH Environment Variable – it’s possibly defined in the source code …
It is not clear what the context the quoted text from chapter 2.9.2 is (e.g. what is the subject of 2.9 where it is part from), but as it is quoted here it is a bit loose explanation IMHO.
It is not really Unix that provides the search path and the interpretation of the PATH variable. The usage of a PATH variable (like all other process environment variables) is defined in the program that interprets it. I assume that in this thread we are talking about the program called bash. And thus the documentation (man page) of bash is where to go about all details of how bash uses it and also about the mechanisms that are offered in bash to create it’s value to one’s needs.
BTW most other shells offer the same (or almost the same) about PATH. And of course other programs may do so when they want to. Problems may arise when different programs support different interpretations of an environment variable.
Sorry, I fail to see the connection between the PATH environment variable and the basename and dirname functions that in fact cut of on the last / in a pathname as offered to the user in the basename and dirname tools.
henk@boven:~> basename a/b/c/d
henk@boven:~> dirname a/b/c/d
Each user’s PATH EV defines at least the following system paths:
In other words both ‘/usr/bin’ and ‘/bin’ –
Taking the example of the “ls” CLI command –
The “ls” in ‘/bin’ is a link to the “real” copy of “ls” located in ‘/usr/bin’ …
Taking the shell as an example of a program – when a command which isn’t a “built-in” command, is given to a shell, the shell will search, in one order or another, the paths listed in the PATH EV for a program with the same name as that typed by the user.
If the shell is cautious, it’ll call “realpath” to check if the program found is really located in the indicated directory or, somewhere else …
A cautious shell will issue a warning with respect to the location of the program being called.