shell scripting topic

cyperghost

@meleu Yes python is on my todo list. It seems to be a great language with a bright future (I hope it will not end like delphi).

cyperghost

@meleu
This can also be usefull for GPIO control
https://github.com/larsks/gpio-watch

gpio-watch uses debouncing on switches and automatically starts scripts on keypress. I compiled it - it's a small binary and it makes GPIO keyevents really really easy!

Out from Readme.md

Watch switches connected to pins 21 only

gpio-watch -e switch 21

If you were to press a button connected to pin 21, gpio-watch would attempt to run:

/etc/gpio-scripts/21


Watch switches connected to pins 21, 22, and 23:

gpio-watch -e switch 21 22 23

If you were to press a button connected to pin 23, gpio-watch would attempt to run:

/etc/gpio-scripts/23 23 0

That is, the event script is called with both the pin number and the current pin value 
to permit a single script to handle multiple events.

meleu

@cyperghost Unfortunately I don't have any electronics knowledge to test this GPIO stuff on my raspi... :/

meleu

@cyperghost said in Mausberry Shutdown Script Doesn't Save Metadata:

Can you please exchange your lines
    emu_command="$(sed -n 4p /dev/shm/runcommand.info)"
    [[ -n "$emu_command" ]] && pkill -f "${emu_command%% *}" && sleep 12 # the value of 12 was suggested by @lostless 
with this one?
emupid="$(sed -n 4p /dev/shm/runcommand.info)"                                #v1.5 @meleu readout 4th line command.info 
emupid="$(pgrep -f "${emupid%% *}")"                                          #v1.5 optain PID emucall by runcommand.sh

if [ "$emupid" ]; then                                                        #v1.5 check correct PID > avoid sleeptimer if shutdown from ES
    kill $emupid && sleep 10
fi    
It is really the better way. Because you check value of command.info ... this value will also be active if you are back in ES so your [[ -n "$emu_command" ]] is always true and the sleep timer will used in every situation. Even if an emulator is not active. So this would be the last version called 1.6 release :)

Look this:

[prompt]$ pkill -f inexistent_process && echo blablabla
[prompt]$ pkill -f inexistent_process ; echo $?
1
[prompt]$

Got it?

cyperghost

--- erased ---

cyperghost

@meleu
About the nerdy stuff :)
https://retropie.org.uk/forum/topic/11750/mausberry-shutdown-script-doesn-t-save-metadata/122

Why you prefer [[ -n ]] rather if [ "$pid" ]
The value in your bracket is always true because runcommand.info will be available and contains values of last emucall even after you go back to ES view (caroussel-mode) and so you try to kill an emulator that is not active and you activate sleep timer.

I extract PID and check if the PID is "true" if not then the value is untrue and so I'm pretty sure there is no emulator actually running and proceed with quitting ES. I'm also sure that 12 seconds aren't needed :) Maybe for a Pi 1/0 :)

See my garbage PID script

PS You should dive into the experience of GPIOs :)

cyperghost

@meleu said in shell scripting topic:

Look this:

[prompt]$ pkill -f inexistent_process && echo blablabla
[prompt]$ pkill -f inexistent_process ; echo $?
1
[prompt]$

Got it?

Yes for sure.... got it!
So the && addition breaks if one condition is not true!
Okay got it :) But I prefer not to use pkill if it is not needed. I would always obtain PID via pgrep and then use kill-command. I think that is just philosophic

Thank you very much

meleu

@cyperghost said in shell scripting topic:

Why you prefer [[ -n ]] rather if [ "$pid" ]

The initial reason was because I like to follow RetroPie's Shell Style Guide, but there's a more reasonable answer here.

The value in your bracket is always true because runcommand.info will be available and contains values of last emucall

I think you already noticed that this isn't true, right?

you try to kill an emulator that is not active and you activate sleep timer.

It's also not true.

This code:

command1 && command2 && command3

is equivalent to

if command1; then
   if command2; then
      command3
   fi
fi

The use of && and || is useful when you have to test something and then execute a single command.

More info about this syntax here: http://mywiki.wooledge.org/BashGuide/TestsAndConditionals#Control_Operators_.28.26.26_and_.7C.7C.29

Cheers!

cyperghost

@cyperghost said in shell scripting topic:

Yes for sure.... got it!
So the && addition breaks if one condition is not true!

I think I answered myself but you explained it now more didactic

meleu

@cyperghost let's get back to the nerdy topic :-)

you said in Mausberry Shutdown Script Doesn't Save Metadata:

#!/bin/bash
emucall=$(sed -n 4p /dev/shm/runcommand.info)
emupid=${emucall#* }
pos=$(expr ${#emucall} - ${#emupid})
$emupid=$(pgrep -f -n ${emucall:0:$pos})
kill $emupid
The code sniplet above should still do the job as it was introduced for a few days and was titled "complex" - it isn't ;)
It's robust string operation and searches for first occurence for space and then kills the latest process :)

Look this example using your approach:

[PROMPT]$ # look how RetroPie calls ScummVM
[PROMPT]$ sed -n 4p /dev/shm/runcommand.info 
bash /home/meleu/RetroPie/roms/scummvm/+Start\ ScummVM.sh "ft"
[PROMPT]$ emucall=$(sed -n 4p /dev/shm/runcommand.info)
[PROMPT]$ emupid=${emucall#* }
[PROMPT]$ pos=$(expr ${#emucall} - ${#emupid})
[PROMPT]$ echo "${emucall:0:$pos}"
bash

Now with the other approach:

[PROMPT]$ emucall=$(sed -n 4p /dev/shm/runcommand.info)
[PROMPT]$ echo "${emucall%% *}"
bash

See? Exactly the same result.

But the bug I reported isn't about this nerdy stuff... I'll expand on the next post... :-)

cyperghost

@meleu Yes...
But I also wrote... to use the -n switch for pkill or pgrep then only the latests process will be killed or PID obtained and all is good :)

My approch about the string operation is following
If you search for the first occurence of " /" then you can be sure you got the name of the running process. I think I must take a deeper look to sed or even awk scripting.

meleu

@cyperghost the bug I reported here happens because the pattern for pgrep -f and pkill -f is a regular expression, and that 4th line on runcommand.info is not a regex and can have characters with special meanings in a regex context.

In my ScummVM example:

bash /home/meleu/RetroPie/roms/scummvm/+Start\ ScummVM.sh "ft"
                                       ^
                                       |
               This plus '+' sign is "confusing" pgrep/pkill

So this is the solution I've found (note: a dot . in a RegEx context means "any character or nothing"):

emu_command="$(sed -n 4p /dev/shm/runcommand.info | tr -d '\\"' | tr '^$[]*.()|+?{}' '.')"
# explaining the crazy pipes above:
# 1. get 4th line of runcommand.info (aka "emulator command")
# 2. delete backslash '\' character
# 3. replace every character that has a special meaning in a regex context with a dot '.'

meleu

@cyperghost said in shell scripting topic:

But I also wrote... to use the -n switch for pkill or pgrep then only the latests process will be killed or PID obtained and all is good :)

In the ScummVM example your approach would return the last bash process. I can't see how you can assure that the most recent bash call is the ScummVM caller one.

cyperghost

@meleu Okay then I was on the wrong way. I thought pkill killed ALL bash calls because it just extracted "bash" so my intentention was to kill only latest bash call and therefore use the coded bash sniplet
Sorry I didn't test with SCUMMVM and so did not realize that there is a problem with the RegEx call :)

I'm really glad you find out!

EDIT:

About latest bash. No that can't be 100% true but 99%
Is SCUMMVM the only caveeat?

cyperghost

@meleu Thank you in advance :) I know you want 100% working solutions and I'm thankfull for your immediate help :) So I see ... when is version 1.7 ready?
It's unbelievable how much energy you invest in such small sniplets.

meleu

@cyperghost

About latest bash. No that can't be 100% true but 99%

As we already realized before, the runcommand.info file persists even after the "emulator" ends. In this case it would fail 100% of the times (we don't want to go with that approach deleting the runcommand.info because we know it's useful for debugging, OK?). :-)

Is SCUMMVM the only caveeat?

Any "emulator" that runcommand.sh calls via shell script. I didn't test but I think that many of those on "ports" are called this way.

cyperghost

@meleu No... (Zdoom, -lr-prboom, lr-tyrquake) there was no problem :)

As we already realized before, the runcommand.info file persists even after the "emulator" ends. In this case it would fail 100% of the times (we don't want to go with that approach deleting the runcommand.info because we know it's useful for debugging, OK?). :-)

1:0

So again - I'm looking forward in v1.7
two versions

Mausberry shutdown script without inotify
Mausberry shutdown script with inotify

About inotify we have to talk later :)

meleu

@cyperghost

So again - I'm looking forward in v1.7
two versions

Mausberry shutdown script without inotify

Mausberry shutdown script with inotify

I would like to emphasize the difference between versions this way:

Shutdown script checking for a change in that file every single second.
Shutdown script that does nothing until that file changes.

:-)

cyperghost

@meleu I will raise Garbage PID detector to v1.1 with your RegEx findings.
thx mate

@meleu PID detector 1.1 is ready. Sorry I used emupid instead of emu_command
It now works 100% flawless ...

cyperghost

@meleu
I pushed the mausberry shutdown script to 1.55 - all kudos to you.
But I want to avoid different usecased. Because some use 1.5 now.
So I think it doesn't matter if there is a v1.7 with better coding style or a v1.55 with more if-then clauses.
All contain your genoius RegEx sniplet that will work in all cases! I hope it is okay for you. In the sake for the best user experience we can give.