22 Responses

  1. Rabbiya at | | Reply

    works. thanks a lot!

  2. dreamer at | | Reply


  3. […] (source code originally found at youness.net) […]

  4. Luis at | | Reply

    Nice ! Thanks…

  5. sysadmin at | | Reply

    The BEST !

  6. Marcel Bootsman at | | Reply

    Thanks, works great!

    Small addition to also modify your lockscreen wallpaper use:
    `gsettings set org.gnome.desktop.screensaver picture-uri file:///tmp/wallpaper.jpg`

  7. Hussein El Motayam at | | Reply


    Just a correction, the shebang is wrong:
    should be:

  8. […] (source code originally found at youness.net) […]

  9. Brian at | | Reply

    it’s possible to use a key-word to set the wallpapers? For example if you set it to “Forest” the wallpapers are going to be random but only using the images of the “Forest” search result on unsplash. (some of the apps in other OS let you do this). how ever thank you for the script, is really cool!

  10. FloWzoW at | | Reply

    Hmm sometimes the wallpaper is just flickering while executing the script and finally black
    there might be a problem with gsettings with my system, but i cant figure it out.

    thanks anyway!

  11. David Oswald at | | Reply

    There are several issues with this I’d like to mention.

    The first: /tmp is a good destination for files that do not need to persist between reboots. It is usually mounted on a physical volume, and as such usually does persist between reboots, but it is not guaranteed to do so. In fact, on some of my systems that have more memory than common sense, I mount /tmp in tmpfs. It doesn’t persist between reboots on those systems. And by in large, this is not a problem.

    The correct place to keep temporary but persistent data is in /var/tmp. So the script in this article ought to be sending the files to /var/tmp instead. This path exists specifically to provide a persistent (between reboots) tempfile destination.

    The second issue: What happens if the device running the cron does not have Internet connectivity. wget will wait for a long time, and then fail. That’s fine, the file won’t get replaced unless there is something replacing it. But it’s a little inelegant. There should be a better safeguard: “wget ….. && gsettings set …” would do the trick, since wget has an exit code of 0 on success or something else on failure. So using the && will only attempt to change the gsettings setting if wget was successful. Along these lines, I would also recommend using a -T timeout for wget so that the system isn’t waiting around for very long.

    The third issue is with regards to Internet connectivity again. There is no attempt to avoid an image download in cases where the device is using a metered connection. I don’t know offhand how to detect this, but I imagine it is probably possible. I’ll look into it and if I can find a solution I’ll follow-up here.

    The fourth issue is regarding atomic writes. In the event of an unexpected shutdown (really in the event of total power loss) there is a risk that the output file could become corrupted. A better solution would be to request a tmpfile using “BGFILE = $(mktemp -p /var/tmp background.XXXXXX.jpg) wget …. && mv $BGFILE current-background.jpg && gsettings set …” By doing this you eliminate the race condition; the file only gets moved into position after a successful fetch, and it’s moved atomically.

    The fifth issue is around run duration. The cron runs every 5 minutes. What if, for some reason, one cron is still in progress while another one kicks off. This is pretty unlikely, particularly if you’re using the -T option with wget, but it’s not totally impossible. To resove this I would recommend touch the destination file, obtain a non-blocking write lock on the target file at the beginning of the process. If the lock cannot be obtained, just gracefully exit, because failure to obtain the lock means that another instance of the cron is in progress. When the cron exits the lock will be released by the kernel.

  12. David Oswald at | | Reply

    I may get something up on Github soon. When I do I’ll follow up here.

  13. David Oswald at | | Reply

    Here’s a proof of concept for most of the ideas I mentioned above:

    The README.md includes a few TODO items I’ll get to within a few days.

Please comment with your real name using good manners.

Leave a Reply