I switched from zsh to bash and extended the PATH variable in
~/.profile by additional directories containing programs.
Despite exporting PATH in ~/.profile my modifications of PATH were
gone after startx.

The culprit seems to be the file svscan@ bf in ~/.66/conf/svscan@ bf --
somehow executed in ~/.xinitrc -- which contains the line
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin
which seems to be responsible for undoing my modification of PATH in
~/.profile.

Whether this should be called a bug may be a matter of taste.
At least, I think that it's no nice behaviour.

I solved the problem in an ad hoc manner by deleting this line.
(Just putting a comment hash at the beginning of this line did
not work.)

I suppose that just deleting cannot be a general solution.

I want to ask the Obarun Team to find some solution to this problem of
resetting PATH during starx since I might not be the only user who
will be afficted by the current situation. And to change the Obarun
install procedures accordingly.

Resetting the PATH variable ist not the only problem there.
There are other variables reset in svscan@ bf, in particular the XDG_*
variables, whose default values some user might have changed in his
~/.profile. I suppose such changes will not survive startx neither.
It is by design, although i did open such related issue at the beginning of my use of Obarun.

Since .profile, .xprofile, .zprofile etc are sourced first before .xsession when using login manager, whatever env vars manually set, PATH included, are reset unless you re-source the same files over again after 66-all runs (.xinitrc or .xsession)..
Thanks for the rapid comment on my question.

What you propose I would call a hack as well; however perhaps
preferable to mine as hacking ~/.xinitrc might be preferable to
hacking somewhere down in the ~/.66 folder.

Unfortunately, sourcing my ~/.profile in ~/.xinitrc did not work. Just
produced a crash of startx. Didn't figure out what kind of things in
~/.profile are responsible for.

I finally added
export MY_PATH=$PATH
at the end of ~/.profile and inserted
PATH=$MY_PATH
in ~/.xinitrc after the value of PATH had been corrupted.
As far as I could see, this seems to work.

But I'm wondering whether there might be a more elegant solution.

For instance, I tried to replace the line
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin
in the file svscan@ bf in ~/.66/conf/svscan@ bf by
: "${PATH:=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin}"
which in normal shell scripts would initialize PATH if still unbound,
but would have no effect if PATH is already bound.
Unfortunately it didn't work.
But svscan@ bf seems not to be just sourced.
I wonder why exporting of the variables set in svscan@ bf could not
achieved by simply putting the respective "export variable" statements
into svscan@ bf and to simply source svscan@ bf.
Or does the complicated evaluation of svscan@ bf do any marvel which
I don't grasp?
i just leave svscan@ <username> alone, and just source my own overrides after 66-all up. You can probably add you own environment vars there, BUT you cannot use variable replacements.
Leaving svscan@ <username> alone is maybe the best hack. Easiest to
implement ;-) Thanks for the suggestion.

Since all variables manipulated and exported in ~/.profile survive
startx there seems to be no neeed to deal with variables in
~/.xinitrc. Nor did I ever do that in the past.
The best way to do it:

- Make a new file called e.g. ~/.66/conf/svscan@ bf/my_var (you can name it as you want as far as the name come after svscan@ bf in the alphabetical order) and changes/add any variable that you want. Note if you want to modify the PATH variable don't use PAHT=$PATH:<new_path> but rewrite entirely the PATH. execl-envfile do not know anything about $PATH term.

Doing this you have your variable set for any user service and shell.
Then if you have specific variable to set for your shell and ONLY for your shell you can make your change at your .profile. Every time you will open a terminal your .profile should be loaded.
Thanks for your proposal.

Unfortunately, I think it has a major drawback: It is very Obarun specific
or maybe I'd better say 66 specific.

I have several Linux distros installed on different computers and I've
also an old Apple laptop, and I use to synchronize via a cloud most of
the dot-files in my home directory, thus assuring a nearly identical
working environment on all these different systems.
An additional file in ~/.66/conf/svscan@ bf/ seems to complicate
synchronization, because this folder doesn't exist elsewhere.

I still don't know how to judge the proposal made by member negative
just to skip the lines in ~/.xinitrc which evaluate the contents of
the folder ~/.66/conf/svscan@ bf/.
As far as I see it seems to work in practice.
So my question is: Does this skipping have any unpleasant consequences
which I haven't yet discovered?
If not, what is this evaluation of ~/.66/conf/svscan@ bf good for?
As far as I know, ~/.profile -- or respective files with other
shells -- seems to be a well-established place in all unix-like
systems for handling environment variables.
Why does Obarun break with this tradition?

An additional minor point:
I would say that usually a terminal doesn't load ~/.profile when opened.
It usually just loads ~/.bashrc.
But there are exceptions: iTerm on Mac OS always loads ~/.profile.
I dont't know how this behaviour changes if we switch to a shell
other than bash, e.g. zsh, which has a different set of initialization files.
Unfortunately, I think it has a major drawback: It is very Obarun specific
or maybe I'd better say 66 specific.
66 specific but not on the way that you think.
An additional file in ~/.66/conf/svscan@ bf/ seems to complicate
synchronization, because this folder doesn't exist elsewhere.
Not all service manager handle user service :). Also, 66 use ~/.66/conf directory whereas e.g. systemd use ~/.config/environment.d/
If not, what is this evaluation of ~/.66/conf/svscan@ bf good for?
it's used to be able to pass environment variables to all user service when its started.
As far as I know, ~/.profile -- or respective files with other
shells -- seems to be a well-established place in all unix-like
systems for handling environment variables.
Why does Obarun break with this tradition?
It does no break any unix-like tradition but maybe you don't know how its works under the hood.
I would say that usually a terminal doesn't load ~/.profile when opened.
It usually just loads ~/.bashrc.
Your assumptions is false here.

The ~/.66/conf/svscan@ <user/ directory is used to define global variable for the s6-svscan program which supervise all user services. That means that every single service launched by the user inherit of these variables. For example, the XDG_RUNTIME_DIR is one of the main variable that a tremendous number of user service relate on. So, having this kind of variable set on the global environment system avoid to define it each time you use/start an user service which depends on it.
As far is a global environment it should be read first to let the user to overwrite it for specific case.

Well, you should read this carefully: https://wiki.archlinux.org/index.php/Environment_variables. As you can see on this wiki page the /etc/profile is used to set global variable(meaning every single user will inherit of it) and only be used for login shells only. That means that on X session every time you open a new terminal this file need to be reloaded.
So now read this carefully in particular the description of the bashrc_profile file: https://wiki.archlinux.org/index.php/Bash# Configuration_files. According to this page if you have an existing ~/.bash_profile the ~/.bash_login and ~/.profile files won't be checked. So, yeah every time you open a terminal bash will read the /etc/profile(which should read and load every files at the /etc/profile.d) but uniquely if your ~/.bash_profile doesn't exist.

Finally, DM usually load the /etc/profile then ~/.bash_profile in that manner of precedence (e.g /usr/share/sddm/scripts/Xsession).
Many thanks for your detailed explanations.
Got a couple of insights.

Powered by Obarun