Handy command-line stuff for terminals or scripts

Sector11 · 2020-11-02 20:47:11

Notice my little script does NOT use "pkill -9".

If running shut it down
If not running, start it up smile

sleekmason · 2020-11-03 01:33:15

*Ouch! Just saw where I may have inferred such inadvertently. Changed to reflect the ld-hotcorners script;)

vasa1 · 2020-11-03 07:03:46

Sector11 wrote:

...
I also have a SSC.sh file to Start|Stop Conky, various ones, that might help you, adapt it for your need:
#!/bin/bash
## Original idea by: GrouchyGaijin
## This idea by: Stinkeye - Jan 2013
## With another tweak by: arclance
## Final tweak by: Sector11
## click to start, click to stop

if pgrep -f "conky -q -c /media/5/Conky/easysid/MechClock/conkyrc_clock"
then
	pkill -xf "conky -q -c /media/5/Conky/easysid/MechClock/conkyrc_clock"
else
	conky -q -c "/media/5/Conky/easysid/MechClock/conkyrc_clock"
fi
It checks to see if the conky is running:
if yes - it kills it
if no - it starts it
Worth a try.
Remember the part inside the " " are the exact command to run the program.

Looks like the "pgrep" bit can be left out:

#!/bin/bash

pkill -xf "conky -c /path/to/conky" || conky -c "/path/to/conky"

ohnonot · 2020-11-06 22:08:11

sleekmason wrote:

What does the -9 do?

http://turnoff.us/image/en/dont-sigkill.png

sleekmason · 2020-11-07 02:27:50

ohnonot wrote:

sleekmason wrote:
What does the -9 do?
http://turnoff.us/image/en/dont-sigkill.png

Ha! This is good:)

sleekmason · 2020-12-11 18:30:27

Made this bit to find which window manager to display in Conky.

wmctrl -m | head -n1 | cut -d" " -f2

rbh · 2020-12-11 20:37:05

How do you manage the need to run as root or with sudo, when in conky?

ohnonot · 2020-12-11 21:17:02

rbh wrote:

How do you manage the need to run as root or with sudo, when in conky?

It comes down to being able to execute commands with superuser privileges without the need of entering a password (interactively).
Several approaches exist: with PAM I guess, or with adding certain commands to your sudoers config files under /etc.
For the latter, see: https://wiki.archlinux.org/index.php/Su … le_entries

ohnonot · 2021-02-15 07:18:53

I was playing around with using conky to display a visual notification from a shell script.
Conky can read config files from stdin! That opens a lot of possibilities...
Proof of concept: find your mouse cursor - displays a red square around your pointer for 2 seconds. Requires xdotool.

#!/bin/sh

showtime=2 # seconds
eval $(xdotool getmouselocation --shell)

cat <<EOF | conky -c - & conkypid=$!
conky.config = {
own_window = true,
own_window_transparent = false,
own_window_colour = '#ff0000',
own_window_hints = 'undecorated,skip_taskbar,skip_pager,sticky',
update_interval = 1,
double_buffer = true,
minimum_width = 20,
minimum_height = 20,
maximum_width = 20,
alignment = 'top_left',
gap_x = $X,
gap_y = $Y,
draw_borders = true,
draw_outline = false,
draw_shades = false,
border_width = 4,
border_outer_margin = 2,
default_color = '#ffffff',
};
conky.text = [[]];
EOF

# total_run_times is unreliable, therefore:
sleep "$showtime"
kill $conkypid

johnraff · 2021-02-15 09:18:36

ohnonot wrote:

I was playing around with using conky to display a visual notification from a shell script.
Conky can read config files from stdin! That opens a lot of possibilities...

Nice find!

---
Other topic:
sh -c '...some code...'
is sometimes useful when you want to run a snippet of shell code from a menu item, Thunar custom action or tint2 or any other situation that doesn't support shell syntax. sh (or bash if you need the extra features) is the command to run, and everything after the -c is just a parameter, so the launcher doesn't have to interpret it at all, just send it to the shell. It's highly advisable to wrap that shell code in single quotes so it won't be touched by anything else.

But this is already well known. Possibly slightly less well known is that you can pass positional parameters to that code snippet, just as if it was a function or separate script in a file.

Try this in a terminal:

sh -c 'echo "First: $1, Second: $2"' _ one two

Just a minute, what's that _ doing? That gets passed as $0, which usually means the shell name or script name. Here it's a placeholder (still accessible as $0) that gets used in error messages:

sh -c  'ecko "First: $1, Second: $2"' mycode one two
# returns:
mycode: 1: mycode: ecko: not found

So sometimes there is value in using a meaningful string in the zeroth place, but usually _ is enough.

More reading:
https://superuser.com/questions/1526229 … ll-code-sh

Last edited by johnraff (2021-03-11 09:00:15)

johnraff · 2021-03-11 09:35:39

queue multiple instances of a script with 'flock'

Flock (comes with util-linux, which you likely have) is used for reliable locking, instead of unatomic lockfiles.

But this use case is something that had been bothering me for a while, and finally websearched up a fix. I'm going to be specific here, because the code is simple but maybe not so easy to understand.

I like audio feedback from scripts sometimes, because I find it less distracting when I'm focussing on something quite different on the screen. Little messages like "backing up somefile" or "yourscript has returned an error!" I use a script called 'say', a wrapper round espeak with tweaked settings. What was annoying me was my shutdown script, which closes dropbox and goes on to do a simple backup. Snippet:

( dropbox stop | say ) &
say "About to do backup mirror to hard disk." &
"$HOME"/scripts/backup-ssd-rsync.sh &

The 'say' commands are forked into the background so that the script doesn't have to wait till it's finished speaking before it goes on to the next operation. Trouble is that if two 'say' messages are triggered one after the other they will overlap and be unintelligable. I want the 'say' script to wait till any previously running instances have finished before speaking its message.

It sounds complicated, but all you need is this code at the top of 'say' (needs bash though):

lock="/tmp/say.lock"
exec {fd}>$lock
flock --timeout 60 "$fd" || exit 1

That will work for any script if you want it to queue up - just choose a differently named lock file for other scripts. You might want a much longer timeout then 60s for scripts that run a long time of course - if the timeout expires the script will give up waiting in the queue.

I could imagine people wanting to queue up media file conversions, for example, might find this useful. cool

The code is simple, but uses redirection and a special bash way of allocating the next available file descriptor - see these pages to read about it, and maybe get some more ideas:
https://blog.skbali.com/2019/03/queue-u … ll-script/
https://stackoverflow.com/a/17030546
https://jdimpson.livejournal.com/5685.html
And 'man flock' of course.

Here's my full 'say' script (the aplay pipe is probably no longer needed):

#!/bin/bash
#say.sh (customized espeak)

# https://blog.skbali.com/2019/03/queue-up-multiple-instances-of-a-shell-script/
# https://stackoverflow.com/a/17030546
# https://jdimpson.livejournal.com/5685.html

lock="/tmp/say.lock"
exec {fd}>$lock
flock --timeout 60 "$fd" || exit 1

hash espeak || {
    echo "$0: needs espeak" >&2
    exit 1
}

if [[ -z $1 ]]
then
    espeak -k20 -s150 --stdout | aplay > /dev/null 2>&1
else
    espeak -k20 -s150 "$1" --stdout | aplay > /dev/null 2>&1
fi

exit 0

Last edited by johnraff (2021-03-12 02:14:26)

brontosaurusrex · 2021-03-11 11:00:05

Neat^, bookmarked.

p.s. I don't get what is {fd} and why it is even needed (but I'll read on when implementing something like that).

sleekmason · 2021-03-11 14:04:10

+1 Bookmarked. This looks like fun:)

johnraff · 2021-03-12 02:12:16

brontosaurusrex wrote:

I don't get what is {fd} and why it is even needed

Man bash > /^redirection > 2nd paragraph

Tricky stuff.

ohnonot · 2021-03-12 19:10:23

fd probably stands for file descriptor.
The most common are stdin, stdout, stderr.
It pays to get aquainted with this.

johnraff · 2021-03-13 02:34:28

^True that this stuff is worth reading up on.

But, the "fd" in this case is just a confusing choice of variable name.
Just confirmed - the code snippet works just as well with {file_desc} + "$file_desc" or, presumably, anything else.
The key is the special use of the { } syntax in this situation.

---
Also, just confirmed that the queue order is not determined by the order the scripts are called:

john@lithium:~$ t1='This is a longish sentence, extended by a few words'
john@lithium:~$ t2='This is another long sentence, extended by a few more words'
john@lithium:~$ t3='This is yet a third long sentence, extended by even  more words'
john@lithium:~$ say "$t1" & say "$t2" & say "$t3" &

Spoke t2 then t1 then t3.
This probably doesn't matter in many cases, but if it did it would need more research...

Last edited by johnraff (2021-03-13 02:38:58)

misko_2083 · 2021-03-14 02:16:52

johnraff wrote:

^True that this stuff is worth reading up on.
But, the "fd" in this case is just a confusing choice of variable name.
Just confirmed - the code snippet works just as well with {file_desc} + "$file_desc" or, presumably, anything else.
The key is the special use of the { } syntax in this situation.
.

That's new. Appeared in bash 4.2

ohnonot · 2021-03-14 05:11:46

misko_2083 wrote:

That's new. Appeared in bash 4.2

Which came out in 2011. What's ten years! These young hip coders, they can never leave a good thing alone... monkey

misko_2083 · 2021-03-14 22:46:48

ohnonot wrote:

misko_2083 wrote:
That's new. Appeared in bash 4.2
Which came out in 2011. What's ten years! These young hip coders, they can never leave a good thing alone...

There will always be someone for whom this will be new.
You are complaining about Gtk3.
Evolution is not progress, it's an adaptation.
Adaptation can go backwards and meet a dead end occasionally.

Last edited by misko_2083 (2021-03-15 08:27:14)

#176 2020-11-02 20:47:11

Re: Handy command-line stuff for terminals or scripts

#177 2020-11-03 01:33:15

Re: Handy command-line stuff for terminals or scripts

#178 2020-11-03 07:03:46

Re: Handy command-line stuff for terminals or scripts

#179 2020-11-06 22:08:11

Re: Handy command-line stuff for terminals or scripts

#180 2020-11-07 02:27:50

Re: Handy command-line stuff for terminals or scripts

#181 2020-12-11 18:30:27

Re: Handy command-line stuff for terminals or scripts

#182 2020-12-11 20:37:05

Re: Handy command-line stuff for terminals or scripts

#183 2020-12-11 21:17:02

Re: Handy command-line stuff for terminals or scripts

#184 2021-02-15 07:18:53

Re: Handy command-line stuff for terminals or scripts

#185 2021-02-15 09:18:36

Re: Handy command-line stuff for terminals or scripts

#186 2021-03-11 09:35:39

Re: Handy command-line stuff for terminals or scripts

#187 2021-03-11 11:00:05

Re: Handy command-line stuff for terminals or scripts

#188 2021-03-11 14:04:10

Re: Handy command-line stuff for terminals or scripts

#189 2021-03-12 02:12:16

Re: Handy command-line stuff for terminals or scripts

#190 2021-03-12 19:10:23

Re: Handy command-line stuff for terminals or scripts

#191 2021-03-13 02:34:28

Re: Handy command-line stuff for terminals or scripts

#192 2021-03-14 02:16:52

Re: Handy command-line stuff for terminals or scripts

#193 2021-03-14 05:11:46

Re: Handy command-line stuff for terminals or scripts

#194 2021-03-14 22:46:48

Re: Handy command-line stuff for terminals or scripts

Board footer