I'm trying to make my random-wallpaper script run every 15 minutes using cron and pywal to change the terminal color pallet. This is my script:
#!/bin/bash
export PATH="$PATH:$HOME/.local/bin/"
files=($HOME/Imagens/wallpapers/*)
image="$(printf "%s\n" "${files[RANDOM % ${#files[#]}]}")"
wal -i $image
And this is the cron line i'm using:
*/15 * * * * DISPLAY=:0 ~/.scripts/random-wallpaper
This works fine when i run it from the terminal and also when using cron on i3wm, but when i switched to gnome it just changes the colors of the terminal as it is suposed to using the new wallpaper as reference, but the wallpaper doesn't change. I tried using DISPLAY=:0.0, using . instead of it, and nothing works.
I need some help figuring out what the issue is.
I came across this post when I was searching for my solution to this. My initial try with wal did something similar to me in awesomewm, where the the terminal colors would change but the background wouldn't. This is what I ultimately did to fix it, though I'm sure it's not the ideal solution. Note that I'm not certain this will work for gnome, as I am bouncing between awesomewm and xmonad. But, you might be able to tweak my approach to suit your needs. I did this with the following cron line:
* * * * * /bin/wal -a 95 -i "$HOME/wallpaper/" -n; DISPLAY=:0 feh --bg-scale "$(< "${HOME}/.cache/wal/wal")"
The important part to note here is the -n flag for wal suppresses wal setting the background (not that that was your issue), but the file path still changes in the .cache/wal/wal file. Also, note that I just pass wal the directory, and it picks a random image from the directory. I then use feh to set the background, but needed to use DISPLAY=:0 to pass the environment variable. I don't know if feh will work to set the background for gnome, but in the very least using wal in this way might simplify your script and perhaps thinking about using something else besides wal to set the background may help. Perhaps you can use gsettings to set the background in gnome, but an initial look tells me others seem to have trouble setting backgrounds with gsettings and cron jobs, but I can't really speak to this as I'm not entirely familiar with how you can set the background in gnome from the terminal (besides running wal from the terminal). Perhaps this post on S.O. will assist you further for doing this in gnome if the above approach using feh doesn't.
Related
I'm attempting to make a Linux system that is meant to run a GUI on top of a window manager, as it requires it for inputs from a device to work. I say attempting because I've been trying for several days but I can't get the bash scripting to work no matter what.
My approach is using a bash script that starts an X session using openbox with nothing on it except for the program I want running on top (I don't care which WM, as long as it's a WM that makes the input work, which I've found that both XFWM4 and Openbox do. I'm willing to use any other that will be better if after testing suggestions those also happen to work).
Once the program is closed (by selecting Quit on it) I'm left with the WM still running, which I don't want, it must go down along with the app, so the system returns to lightdm's login screen.
I can't modify what the quit command on it does either; would take a long time recompiling and modifying such a big app for something so trivial. This is why I really need the WM to go down by itself when the app's process is gone.
I've tried using the openbox autostart script and also a custom script that is run using the .desktop file that is found by lightdm. All my attempts end up with a script that simply kills the display right after entering the session.
I just want something simple like this:
#!/bin/bash
openbox &
guiapp; openbox --exit (or killall Xorg whatever)
But this syntax won't work. I've tried using things like pid=$(pgrep guiapp) to make it look for the PID every bunch of seconds and if it's not there, kill the WM or Xorg entirely; but those also didn't work, I don't know if my attempts were bad or what. Sorry I can't put those examples since I didn't make backups of my script attempts and I've been trying for quite a long time without success.
I really hope someone can help me.
I finally got it working! I found a post online that was attempting a similar thing to mine and he did this approach:
in ~/.config/openbox/autostart:
xsetroot -solid black &
gnome-terminal --full-screen --hide-menubar -e guiapp &
/etc/guiapp/Exit.sh &
in /usr/share/xsessions/gui.desktop:
[Desktop Entry]
Name=OpenBox Session
Exec=openbox-session
TryExec=openbox-session
Finally the actual solution in /etc/guiapp/Exit.sh:
#!/bin/bash
until [[ $(pidof guiapp) ]] ; do
sleep 1
done
while [[ $(pidof guiapp) ]] ; do
sleep 1
done
openbox --exit
His task was slightly different but all it took was some slight modification of his exit script to tailor it to what I wanted.
This way, LightDM will run OpenBox with the flag telling it to read the autostart script, and autostart will run both the app and a script that will keep looking for the pid of my app every second, and when it's down, it'll quit OpenBox to the login screen automatically, so I can switch to a different DM. Just how I wanted it!
I have been given a personal profile on a linux project server running bash 3.2.15. Every time I run a command it echoes the text of the command to screen. This isn't a serious issue, but it bugs the crap out of me. I can't find any specific command in .profile or .bashrc that sets this up, and everything I find through google is how to enable it. Not how to disable it. Anybody got any ideas?
It sounds like debugging has been enabled (using set -x). You can disable it using set +x.
I have a "stock" xmonad install on Arch.
No changes to my xmonad.hs yet
I have installed dmenu.
It runs by alt-p, the default, and displays and filters as expected.
Chromium runs, but other items, like ranger, alsamixer or other tasks do not.
I am not finding anything anywhere about anyone having to do anything to get these items to run, nor anyone having any issues with doing so.
Surely, then, there is something wrong in my install.
my dmenu_run is as follows:
#!/bin/sh
dmenu_path | dmenu "$#" | ${SHELL:-"/bin/sh"} &
I would normally run terminology with bash or zsh. I have tried to alter the SHELL to /bin/bash, but to no avail.
Is there any other place I must look or items I should alter?
Such a shame as I am really liking xmonad so far, and want to get dmenu working before I start exploring xmonad.hs...
Thanks in advance
UPDATE: I have found the following
here over at Archwiki that involves changing dmenu_run and adding a .demenu_term in one's home. It seems to work, but still wonder if there was a more orthadox mechanism.
ranger and alsamixer are applications which run inside a terminal. Imagine (or try) to run ls via dmenu, where should the directory listing be printed to without a terminal?
You look for functionality which is provided either by prompt imported from XMonad.Prompt.Shell by using a convinient keybinding like
((modm .|. shiftMask, xK_c), prompt ("xterm" ++ " -e") greenXPConfig)
(described in the linked documentation) or shellPrompt where you execute
xterm -e alsamixer
or any other command, e.g.
feh path/to/image/you/want/to/open/now.jpg
instead of opening a terminal, running above with tailing & and exiting the terminal.
Some of my build commands use the osx command say to notify me of progress whilst I continue to work. Generally, they use a gentle female voice, but when I run the command as sudo there is a rather gruff manly voice telling what's going on.
I think it would be useful if sudo commands had a similar visual clue to their output, so maybe the output could be prefixed with * or the colour changed to bright yellow or something alike. Is there any way to achieve what I want?
Maybe I could create an alias for sudo which changes the colour of output, then continues to issue the sudo command - but I don't know how to get the colour to be changed back.
Is there any existing system to enable this tweak?
Use alias sudo="tput setaf 1; sudo".
To change the color back, simply add tput setaf 0 to your PROMPT_COMMAND (in the .bashrc)
I'm trying to write a web frontend for Crontab in Ruby using the excellent CronEdit gem. I went through Dillon Cron's crontab source code and found that it updates a particular file so that the daemon will refresh the cron list during the next sweep.
In man crontab for VixieCron, it says:
Additionally, cron checks each minute to see if its spool directory’s modtime
(or the modtime on /etc/crontab) has changed, and if it has, cron will then
examine the modtime on all crontabs and reload those which have changed.
Thus cron need not be restarted whenever a crontab file is modified. Note that
the crontab(1) command updates the modtime of the spool directory whenever it
changes a crontab.
Is there any platform (Ubuntu, Red Hat, ArchLinux, Mac OS X) independent way to ensure that after manually editing the Cron file, the daemon refreshes it without fail?
No, there isn't. If you know it's VixieCron, then update the timestamp of the directory. Otherwise, you might be able to fake it: Set the env variable EDITOR before you invoke crontab -e (which should bring up an editor for the crontab).
The idea is to set the editor to some program which makes the change. crontab -e will wait for the editor to terminate and reread the file and tell cron that something has changed.
If you have an old version of cron, though, you must still restart it. But I doubt that you can find such ancient versions on anything that runs Linux or Mac OS X.
Sane modern linux distros have /etc/cron.d/ directory where you can put your crontab entry as a separate file. If I recall correctly the new cronfile gets read within 2 minutes of being written
Thank you very much gnibbler and Aaron. I just went through the source code for both 'whenever' and 'cronedit' gems for Ruby. Both of them does a 'crontab -' which replaces the existing cron file with the updated cron entries. That means contrary to my original question, these libraries make use of the standard crontab tool which in turn would do whatever specifics necessary to refresh the daemon.
I think the best platform-independent, and cron (dillon, vixie, mcron etc.) agnostic way to refresh the daemon is to always use the associated crontab utility. Even when editing programmatically, the user-program must pass the new cron file to the crontab utility which would do whatever is required by that specific platform/cron.
#Mark, thank you for the comments. However, I'm trying to provide a simple web frontend that the user can customize through the www just like editing the crontab file directly.
Thank you so much for your responses!
If this is that important, why not use a different lever? In other words, there are two options:
crontab 1: /do/some/very/specific/thing with specific parameters that i need to change etc.
crontab 2: /do/what/needs/to/be/done
In #2, the job is responsible for determining at run time what needs to be done and doing it. With this design, the notion of needing to understand how crontab works on some detailed level is irrelevant.