I know that editing files in /etc/rc.d, or /etc/cron.d may cause a script to run on system start up, but it will do so regardless of the desktop environment/window manager being used. I would like to know a way to execute a script on start up of i3 only. The script I want to execute is ~/.xsession which includes a command that sets the desktop background using feh. I do not want this script executed for other desktop environments/window managers because they use other methods to set desktop background and I do not want the two methods to conflict. Any ideas on how to do this?
I admit that it may be stupid, but I never heard of i3. Looked it up in Wikipedia, thus you will understand ny knowledge is limited.
As it seems to be (part of) the windows manager, it is NOT part of the system (as you already found out, doing things on system startup/boot is not related to what you want *) ), but it is also NOT part of the desktop. So when you talk about “other desktop environments” I am at a loss.
OTOH, it assume it is the DE that decides what to use as background for the desktop (using the capabilities of the Windows manager). Thus I am still more confused about what you want where.
But as I warned you above, my knowledge on i3 is very limited.
================
*)
Oh yes, as a side excursion, using /etc/rc.d and friends is SysVinit and openSUSE already for some years does not use it anymore, but went to systemd.
That is for backward compatibility. Systemd will still operate on it, but you are strongly discouraged to do any development (let alone create new entries) on it.
But this was only a warning and as I said a side excursion because it has nothing to do with your question.
I re-read your first post above. You are talking about ~/.xsession.
Do I understand correct when I think that you want ~/.xsession to be executed when the user’s X (being i3) is started?
I do not know if i3 works the same as X11 in this respect (running xsession scripts), but today it is often the display manager that decides on the fact which DE is started if ~/.xsession is run or not because DEs might have their own mechanism of doing things at their startup.
I think your lack of experience of i3 is causing some confusion here. i3 isn’t used by any DE. I don’t think it even can be, it’s a standalone WM, it even has its own .desktop file in /usr/share/xsessions. If you’ve ever encountered the WMs Awesome or bspwm I can say it is similar in that all three do not and to my knowledge cannot serve as a component of a DE. To be clear, I am grateful you’re trying to help and I hope this does not come across as an attack as I really am grateful you’re trying.
Can you not just create an autostart script to set the desktop background? Just check the $DESKTOP_SESSION environment variable to know the i3 is the active WM.
It does not come across as an attack ;). I already said my i3 knowledge is very limited and I am trying to learn. What I basically am trying is to get clear what functionality we are talking about and the correct terms that belong to them. This will probably narrow down the number of places/hooks were a solution might be implemented.
But it means that:
but no other DEs/WMs
should be read as
but no other WMs
because there is no DE at all when you run i3 and when a DE is started, it never uses i3.
IMO maybe a re-consideration of relevant issues might be helpful…
Originally,
It sounds like the thought was that the i3 environment might need to be detected, and then perhaps on every boot an i3 configuration be applied.
A follow up Q might be whether you really need to detect whether the i3 WM is active.
In a small enough network, you might know by various means.
Or, perhaps just install i3 on every machine as an option(not necessarily used) with your special configuration.
In fact,
I’d recommend my last suggestion above as the simplest, least complicated so would likely cause least problems.
Since the i3 WM is available from openSUSE repos (The search URL follows) https://software.opensuse.org/package/i3
It would be next to trivial to script the installation plus writing your custom configuration to every machine and you wouldn’t even have to touch every machine if you have remote access.