shell scripting topic
-
@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
-
@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... :-)
-
@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. -
@cyperghost the bug I reported here happens because the pattern for
pgrep -f
andpkill -f
is a regular expression, and that 4th line onruncommand.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 '.'
-
@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. -
@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? -
@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. -
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 theruncommand.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. -
@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 :)
-
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.
:-)
-
-
@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. -
@cyperghost said in shell scripting topic:
I hope it is okay for you.
C'mon man! Every line of code I post in this forum can be considered public domain. ;-)
Use it the way you want!
-
@meleu okay PD-meleu
-
@cyperghost said in Mausberry Shutdown Script Doesn't Save Metadata:
I think so, but I'm pretty sure that your solution (ScummVM fix) is already in usage by @hansolo77
Your posted script is still using this:
emupid="$(pgrep -f "${emupid%% *}")"
Which gets only
bash
on ScumVM case. Maybe you want to change it to v1.56 and useemupid="$(pgrep -f "$emupid")"
-
@meleu Thx my friend
-
@meleu About the inotify thing.
Do you have any clue why the GPIO signal is not detected? At first it works only if you have root access - but I'm pretty sure you already know. As far as I looked to v 1.6 of your code it should work without any problem.If there are any issues you can try to use GPIO control
If you watch Pin26 for a switch via GPIO control just place file
26
(without .sh!) to/etc/gpio-scripts/
and give theecho 1
> command in this file.26
#!/bin/bash #this is the GPIO pin connected to the lead on switch labeled OUT GPIOpin1=23 echo "1" > /sys/class/gpio/gpio$GPIOpin1/value
-
@cyperghost said in shell scripting topic:
@meleu About the inotify thing.
Do you have any clue why the GPIO signal is not detected?it's pretty hard to test things without the respective thing! :-)
I've made some tests with @lostless (I was giving instructions via IRC) and he was able to turn off his raspi with
echo 1 > /sys...
, but not with the switch pressing.Then I'm pretty sure that my method works as expected, but there's something in the Mausberry switch that I'm not able to diagnose...
-
@meleu I also have no clue why the thing won't catch up.
I tried to loadinotifywait
throug rc.local and it worked.
As I changed the monitored file I get a note and the process inotifywait finished.I've made some tests with @lostless (I was giving instructions via IRC) and he was able to turn off his raspi with echo 1 > /sys..., but not with the switch pressing.
It would be interesting to see what is happening internal through the GPIO if you press a button. Maybe it's better do use an more "advanced" bibliothek like wiring pi. Because with wPi you can detect flanks. But that's the suggestion I made by using an driver to detect keypresses.
-
@cyperghost Just to share some bash coding knowledge, I would like to make some comments about your bash coding philosophy :)
- the bash scripting language is an interpreted programming language
- if you google about "compiled vs intepreted language" and you realize that interpreted languaged tends to be slower.
- type
man bash
on your terminal, go the end of the bash man page and look at the first sentence in the BUGS section. ;-)
Why is @meleu trying to convince me that bash is slow if he loves bash?
Well, I love bash because it is widely used. If it wasn't for that I would have migrated to zsh (which is even more powerfull), but let's not go deep into this nerdy stuff...
I'm talking all those things because of your very good practice of checking if everything is really fine before running a command. In other languages, if you don't do these checkings, the program may crash. But when coding bash scripts (or any other shell language) it's a better yet practice to take advantage of every chance you have to optimize things.
I'm talking specifically for this part:
if [[ -e "/dev/shm/runcommand.info" ]]; then emupid="$(sed -n 4p /dev/shm/runcommand.info | tr -d '\\"' | tr '^$[]*.()|+?{}' '.')" emupid="$(pgrep -f "$emupid")" fi if [ "$emupid" ]; then kill $emupid && sleep 9 fi
You're making bash check if the
runcommand.info
exists, butsed
already does that.
You're getting the emulator's PID withpgrep
, butpkill
won't kill anything if there isn't a process matching the pattern.That's why I would change all the logic above with this here:
emupid="$(sed -n 4p /dev/shm/runcommand.info | tr -d '\\"' | tr '^$[]*.()|+?{}' '.')" [[ -n "$emu_command" ]] && pkill -f "${emupid}" && sleep 9
That's it. :-)
Cheers.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.