You must log in or register to comment.
I’ve found out the hard way: Running the script during startup, and running it using the proper user authorization, are two different things.
And environment —
DISPLAYandPATHin particular.You’re right and I’m dumb. I forgot to absolute-ify one of the paths, which caused the script to be dependent on my user environment, which isn’t loaded by the desktop file.
Weird that it doesn’t work. The usual way to run scripts on startup is through systemd units though. That has the added benefits of automatically logging all output and letting you control it through commands like
systemctl enable <unit name>. It’s a really neat system, and I highly recommend learning it if you see yourself doing this kind of automation more often.The usual way to run scripts on startup is through systemd units though.
Even worse than via some utility of your window manager
You can also get cron to do it.
I miss the days of just sticking it in /etc/rc.local
Hey everyone, get a load of this fool drinking from an
I ♥️ SYSVmug! Ha!hides Lennart Pottering dartboard while everybody’s distracted
I do that when I want it running with root privileges.
In case of user privileges though, the autostart is a better idea.You was m can use user units too if you want them scoped to your user.
Yeah, I forgot to tell the full thing.
In case of User Privs and GUI. That is much easier to do by just adding it to Autostart.
When all else fails…
crontab -e@reboot sleep 300 && sudo ./myshell.sh(this is actually broken on some distros)
Though, not every cron supports that.
Also, if you are packaging software, you have to do it the right way. But if not, it’s often easier to go and install an init script.
I’ve been in the systemd world so long none of my systems even have cron
That sounds like a sad world. I like cron
Reject systemd embrace bashrc.
