Inside my ~/Pictures/wallpapers/ folder I have a shell script that changes the wallpaper using a while true each time the sleep function terminates:
feh-auto.sh
#!/bin/bash
while true; do
feh /home/maruko/Pictures/wallpapers --randomize --bg-fill
sleep 1800
done
this script is automatically run each time the laptop powers up, or the i3 configuration is reloaded in place using the shortcut Win+Shift+R:
~/.config/i3/config
...
### CHANGE WALLPAPER RANDOMLY
# https://www.linuxandubuntu.com/home/set-background-wallpapers-on-i3wm
exec_always --no-startup-id ~/Pictures/wallpapers/feh-auto.sh
...
Making changes to the i3 configuration is usually accompanied with a reload in place, so that said changes take place.
The problem is that each time a reload occurs, a new instance of feh-auto.sh is also created, meaning that now instead of 1 timer, I have multiple timers of 1800, that will change the wallpaper x times where x is the number of times I reloaded the configuration.
I would like a more appropriate behavior as I reload: check if feh-auto.sh is already running and if it is, do not create a new instance.
Could you please guide me to the best solution?
Thank you.
EDIT
As #balki suggested in the comments, I have created a cron job
(sudo crontab -e)
#reboot /home/maruko/Documents/program-files/shell/feh-auto.sh
to run the following script
feh-auto.sh
#!/bin/bash
export DISPLAY=0:0
feh /home/maruko/Pictures/wallpapers/ --randomize --bg-fill
However, when booting up or rebooting the system, the wallpaper is blank as if nothing really happened. The command sudo systemctl status cronie.service reports the following:
crond[3300]: pam_unix(crond:session): session opened for user root(uid=0) by (uid=0)
CROND[3307]: (root) CMD (/home/maruko/Documents/program-files/shell/feh-auto.sh)
CROND[3300]: (root) CMDOUT (feh ERROR: Can't open X display. It *is* running, yeah?)
CROND[3300]: (root) CMDEND (/home/maruko/Documents/program-files/shell/feh-auto.sh)
CROND[3300]: pam_unix(crond:session): session closed for user root
I don't know what to do next.
The answer to this post is to read documentation:
i3 config comes with the exec and exec_always commands:
exec will execute the command once at boot,
exec_always will execute the command on reloads too.
The solution is to substitute the above call to feh-auto.sh:
~/.config/i3/config
### START FEH WALLPAPER
# note: exec_always will run the script on each reload, not ideal
# --no-startup-id will eliminate the problem of loading icon on boot
exec --no-startup-id /home/maruko/Pictures/wallpapers/feh-auto.sh
Related
I've just switched to fish-shell
And I've used the instructions of How do I run a command every login? What's fish's equivalent to .bashrc?
Which means I've moved the commands which i prefer to run upon login from .bashrc to ~/.config/fish/config.fish
But right now the commands keep running if i open screen or tmux session ! but before while i were using the default shell that's was never happens (meant that the commands were only run during the login and never re-run in screen session)
How to avoid this?
Thanks in advance.
You can test for the TERM environmental variable to see if your shell is running in such a session. Both screen and tmux by default set it to 'screen'.
if not string match --quiet -e $TERM 'screen'
<your startup scripts>
end
Note that other useful indicators are whether a shell is interactive or a login shell. You can use status --is-interactive and status --is-login to check for these two states.
In your specific case, a check for login shell might be what you are looking for:
if status --is-login
<your startup scripts>
end
See https://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell for an explanation.
I want to run a .sh script once whenever a logon is made (including logons made after a suspend)
It should run in the background, so no shell poping up
The script is the following
#!/bin/bash
# Bash script to refresh the Extend Panel Menu extension that puts the clock in the wrong place after logon
gnome-shell-extension-tool -d extend-panel-menu#julio641742
sleep 1
gnome-shell-extension-tool -e extend-panel-menu#julio641742
It just refreshes an extension that I have in Ubunto 18.04 that gets misconfigured in every logon I do.
How can I make it run automatically after those logons?
I'm opening an ssh-session to a remote server and execute a larger (around 1000 lines) bash-script on the remote machine. It involves several very CPU-intensive calls which run for up to three minutes each. To track the scripts progress it echoes messages placed at several points in the script.
In general the script runs smoothly. From time to time the script runs trough (the resulting file on the remote machine is correct) but the output to the terminal stops. Ctrl-C doesn't help, no prompt, just a frozen session. top in a separate session shows normal execution of the script.
My question: How keep the session alive?
local machine:
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.9
BuildVersion: 13A603
remote machine:
$ lsb_release -d
Description: Ubuntu 12.04.3 LTS
Personally, I would recommend using screen or tmux on the remote terminal for exactly this reason.
Those apps will allow the remote process to continue even if your local SSH session times out.
http://www.bangmoney.org/presentations/screen.html
http://tmux.sourceforge.net/
Start a screen on the remote machine and run your command from it:
screen -S largeScript
And then
./yourLargeScript.sh
Whenever your ssh session gets frozen, you can kill it with ~.
If you ssh again, you can grab back your screen by:
screen -dr largeScript
Make it log to a file instead (perhaps via syslog), and tail that file from wherever is convenient for you. This also helps detach the script so you can run it headless, from a cron job, etc. Also, if the log file has read access for others, they too can monitor it.
This hopefully should be an easy question to answer. I am attempting to have mumble-ruby run automatically I have everything up and running except after running this simple script it runs but ends. In short:
Running this from terminal I get "Press enter to terminate script" and it works.
Running this via a cronjob runs the script but ends it and runs cli.disconnect (I assume).
I want the below script to run automatically via a cronjob at a specified time and not end until the server shuts down.
#!/usr/bin/env ruby
require 'mumble-ruby'
cli = Mumble::Client.new('IP Address', Port, 'MusicBot', 'Password')
cli.connect
sleep(1)
cli.join_channel(5)
stream = cli.stream_raw_audio('/tmp/mumble.fifo')
stream.volume = 2.7
print 'Press enter to terminate script';
gets
cli.disconnect
Assuming you are on a Unix/Linux system, you can run it in a screen session. (This is a Unix command, not a scripting function.)
If you don't know what screen is, it's basically a "detachable" terminal session. You can open a screen session, run this script, and then detach from that screen session. That detached session will stay alive even after you log off, leaving your script running. (You can re-attach to that screen session later if you want to shut it down manually.)
screen is pretty neat, and every developer on Unix/Linux should be aware of it.
How to do this without reading any docs:
open a terminal session on the server that will run the script
run screen - you will now be in a new shell prompt in a new screen session
run your script
type ctrl-a then d (without ctrl; the "d" is for "detach") to detach from the screen (but still leave it running)
Now you're back in your first shell. Your script is still alive in your screen session. You can disconnect and the screen session will keep on trucking.
Do you want to get back into that screen and shut the app down manually? Easy! Run screen -r (for "reattach"). To kill the screen session, just reattach and exit the shell.
You can have multiple screen sessions running concurrently, too. (If there is more than one screen running, you'll need to provide an argument to screen -r.)
Check out some screen docs!
Here's a screen howto. Search "gnu screen howto" for many more.
Lots of ways to skin this cat... :)
My thought was to take your script (call it foo) and remove the last 3 lines. In your /etc/rc.d/rc.local file (NOTE: this applies to Ubuntu and Fedora, not sure what you're running - but it has something similar) you'd add nohup /path_to_foo/foo 2>&1 > /dev/null& to the end of the file so that it runs in the background. You can also run that command right at a terminal if you just want to run it and have it running. You have to make sure that foo is made executable with chmod +x /path_to_foo/foo.
Use an infinite loop. Try:
while running do
sleep(3600)
end
You can use exit to terminate when you need to. This will run the loop once an hour so it doesnt eat up processing time. An infinite loop before your disconnect method will prevent it from being called until the server shuts down.
I have a custom shell script that runs each time a user logs in or identity is assumed, its been placed in /etc/profile.d and performs some basic env variable operations. Recently I added some code so that if screen is running it will reattach it without needing me to type anything. There are some problems however. If I log-in as root, and su - to another user, the code runs a second time. Is there a variable I can set when the code runs the first time that will prevent a second run of the code?
I thought to write something to the disk but then I dont want to prevent the code from running if I begin a new terminal session. Here is the code in question. It first attempts to reattach - if unsuccessful because its already attached (as it might be on an interruped session) it will 'take' the session back.
screen -r
if [ -z "$STY" ]; then
exec screen -dR
fi
Ultimately this bug prevents me from substituting user to another user because as soon as I do so, it grabs the screen session and puts me right back where I started. Pretty frustrating
The ${PPID} of the shell you get when you su will be the su command. So the output of
ps -o command= $PPID
will begin with the letters su, so test for this.
I think you can get this right if you read the following post (and the man for your favorite shell)
Question about login vs profile