Bash question

J_Szucs · 01-05-2003, 07:11 PM

I have a very simple bash script that
1. Prepares a wav.lock file
2. Starts an external program to record some audio into wav until CTRL-C is hit
3. Should delete the wav.lock file

My problem concerns step 3:
When CTRL-C is hit not only the audio recorder is stopped but the script itself, too, so step 3 is not executed and thus the lockfile is never deleted.

Is there an easy way to have the script execute a command on exit, or an other trick?

moses · 01-05-2003, 07:16 PM

man bash
search for trap

crabboy · 01-06-2003, 11:20 AM

Code:

#!/bin/sh

SigInt()
{
    echo "Caught SigInt"
}

trap "SigInt 2" INT

# Start script here
echo hello

J_Szucs · 01-06-2003, 05:23 PM

Thank you all,

Trap works

J_Szucs · 01-12-2003, 08:40 PM

Not that it was a great problem since my script basically works now, but I found something that I do not understand with trap:

I simply used a
trap 'rm -f lockfile' 2
line following the lock file creation.

I read somewhere in the bash manual that in this case bash traps the signal, executes the command and exits.
But it is not the case: bash seems to continue the script after execution of the command on the trap line. (So I had to change step 3 to a conditional command to avoid errors)
Did I miss something in the bash manual?

unSpawn · 01-12-2003, 08:59 PM

No, you have to disable trap.
Here you get a msg on CTRL+C, the next CTRL+C stops the script:
SigInt() { echo "Caught SigInt"; trap INT; }

moses · 01-12-2003, 09:04 PM

It depends on the signal, and whether you are in the process of
executing a command or not. . .

Quote:

When bash receives a signal for which a trap has been set
while waiting for a command to complete, the trap will not
be executed until the command completes. When bash is
waiting for an asynchronous command via the wait builtin,
the reception of a signal for which a trap has been set
will cause the wait builtin to return immediately with an
exit status greater than 128, immediately after which the
trap is executed.

Under the "trap" section header in the man page, it basically
says that if the signal is an exit, the shell executes the trap
command and then exits, but if it's something else, it behaves
differently.
Your signal is an exit, so it should wait for a command to
execute (if necessary), then execute the given command, then
exit. There must be some minor syntax error in your code, but if
you've got it working, then. . .

J_Szucs · 01-12-2003, 09:34 PM

Here is the script:

CEL=/home/szucs/media/zene/szetszedni
echo "" > $CEL/$1.tapeq.wav.lock
trap 'rm $CEL/$1.tapeq.wav.lock' 2
wavrec -t4000 -s 44100 -S "$CEL"/$1.tapeq.wav
if [ -f $CEL/$1.tapeq.wav.lock ]; then {
rm $CEL/$1.tapeq.wav.lock;
}
fi

File creation takes no time, so CTRL+C always stops wavrec.
Then removes the lockfile, then it tried to remove it again, until I inserted the second rm command in the if...fi block.
I do not think there is a syntax error in it, but who knows...
And yes, it basically works (it only could be two lines shorter).

crabboy · 01-12-2003, 10:29 PM

Your script looks like it will do the job. One question though. Who checks for the existance of the lock file?? wavrec? I modifed your script to exit if it finds a lock file with the same name and made it a bit easier to maintain.

Code:

BASE_PATH="/home/szucs/media/zene/szetszedni"
WAV_FILE="${BASE_PATH}/$1.tapeq.wav"
LOCK_FILE="${WAV_FILE}.lock"

SigInt()
{
   echo "Caught signal, removing lock file"
   rm $LOCK_FILE
}
 
if [ -f ${LOCK_FILE} ]; then
   echo "Lock file [${LOCK_FILE}] exists exiting."
else
   echo "" > ${LOCK_FILE}
fi

trap "SigInt 2" INT

wavrec -t4000 -s 44100 -S ${WAV_FILE}

if [ -f ${LOCK_FILE} ]; then
   echo "application exited, removing lock file"
   rm ${LOCK_FILE}
fi

J_Szucs · 01-13-2003, 03:19 AM

Thank you crabboy, your code really looks much smarter. I just tend to be rather lazy when writing code...

As for the lockfile: it is used to avoid conflicts with my 'batch-mode' mp3 creating script (which uses command line utilities to automatically cut several albums into tracks, remove trailing silence, normalize volume and encode in tape or cd quality).
The lockfile ensures that encoding of an album cannot start while it is being recorded.
Other conflicts are unlikely since only one wav can be recorded at a time (having only one sound card and one line input).