shell scripting topic

cyperghost

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.

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