scripting q-- wait for response?

[gerald_clark]

It is hard to say why an unrevealed script does not run.

[mb0]

so you are saying there is no reason  to expect a script not to be launched fine from bootlocal.sh?#

e: here is an example that doesn't work; (remember, which works when ran manually)

#!/bin/sh
while true
do
        /usr/local/bin/mpc idle > /dev/null
        LINE=`/usr/local/bin/curl -s 127.0.0.1/test`
        curl -F "var=$LINE" 127.0.0.1:5678
done

saved as /opt/script.sh, with '/opt/script.sh &' in bootlocal.sh

[gerald_clark]

If it is executable, and you call it from bootlocal.sh, it will run.
It is your responsibility to insure that it runs to completion an does not hang on a line such as
/usr/local/bin/mpc idle > /dev/null.

bootlocal.sh runs as root without a stdin, so any program requiring keyboard input will fail.
It also runs files synchronously, so any program that does not return will hang bootlocal.sh.

[mb0]

again, how would i run this script on startup??

(and FWIW, i thought the & addition would stop it from blocking?.. as well as this i had it at the end of the scipt.
FYI there is no keyboard input required)

[gerald_clark]

It is your script.
You will have to figure out why it is not running as expected.
I cannot troubleshoot secret scripts, and have lost interest.

[mb0]

Excuse me, i posted my script just two posts ago. It runs as expected when i run it manually. Therefore, there is not a fundamental problem with the script.

[Rich]

Hi mb0
I don't know what the problem is, but I will make a couple of comments.
1. Are you sure  it's not  running? If you start  top  or execute  ps, does it show up?
2. I don't know what those commands do,  but if their execution time is short, you will suck up a lot of CPU cycles.
    If that's the case, it might be slowing down another process that is trying to start up, maybe one you are relying on.

[mb0]

Thank you for your reply rich. The execution time is not short. often minutes. the rest of the startup seems fine. i will look into your first point tomorrow.

[Rich]

Hi mb0
When troubleshooting a problem it can be helpful to have feedback. Since you are backgrounding the script, I
don't know if an echo command will work, but this will:

Code: [Select]

#!/bin/sh
while true
do
        /usr/local/bin/mpc idle > /dev/null
        touch one
        LINE=`/usr/local/bin/curl -s 127.0.0.1/test`
        touch two
        curl -F "var=$LINE" 127.0.0.1:5678
        touch three
doneIf the script ran, ls will return the files one,two, and three. If you delete them and the script is still running, they will
be recreated.

[gerald_clark]

Better make that /tmp/one, /tmp/two, /tmp/three.

[Rich]

Yeah, from a point of keeping the file system uncluttered, that is a cleaner approach.

[maro]

Yeah, from a point of keeping the file system uncluttered, that is a cleaner approach.

Well, that as well as the fact that it could be quite a bit of guesswork to find out in which local directory a script was executed.

My general rule of thumb for trouble shooting a script that "the system" starts (e.g. one called by 'crobtab'): I'd tend to use pretty much only absolute file names. After I've identified what typically was a wrong assumption on my part I remove any surplus use of  these absolute file names again, as they are IMHO not a "good look" in general terms.

[H.Lunke]

The execution time is not short. often minutes. the rest of the startup seems fine.

Hi mb0,

'mpc' does not return until an event is generated, such as changing the playlist, pausing the player and so on. So the following works fine even when run from bootlocal.sh via: /path/to/script.sh &

Code: [Select]

while true;do echo `date;mpc idle`;done >/tmp/logfile
After reboot you should be able to watch the growing logfile via: "tail -f /tmp/logfile" - sure there should be some player activities ongoing..

You could also write the loop as follows:

Code: [Select]

while echo `date;mpc idle`;do mpc >/tmp/logplay;done >/tmp/logevent
This way "/tmp/logplay" contains the song currently played (if any) and "/tmp/logevent" contains status change messages.