shell scripting topic

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.

meleu

@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!

cyperghost

@meleu okay PD-meleu

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 use

emupid="$(pgrep -f "$emupid")"

cyperghost

@meleu Thx my friend

cyperghost

@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 the echo 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

meleu

@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...

cyperghost

@meleu I also have no clue why the thing won't catch up.
I tried to load inotifywait 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.

meleu

@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, but sed already does that.
You're getting the emulator's PID with pgrep, but pkill 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.

lilbud

@meleu Me after reading that whole post
0_1501613667625_b69a7a0f-c51a-4d8b-ab8e-27144bb02dbe-image.png

meleu

@lilbud this topic was created exactly to avoid this reaction on other people's topics. :-)

cyperghost

@lilbud You're welcome to ask and post things affecting bash :)

lilbud

@cyperghost OK, I have very little experience with code and zero experience with bash.

Where in the hell do I start?