1

I have a Bash script of a thousand lines each containing an ffmpeg command. I start this with source script and it runs just fine.

However, when I try to take control of this script in various ways, things go completely awry:

  • If I do Ctrl + Z to pause the whole thing, only the current ffmpeg command is paused, and the next one is started! Not what I wanted!
  • If I do Ctrl + C to stop everything, the script jumps to the next ffmpeg command, and I have to press once for every line in the script to finally stop everything. Sheer hell.
  • I tried using ps -ef from another shell to locate the source command to pause/kill it from there, but it does not exist in the list.

So how can I pause/stop the parent script the way I wish? Or possibly, how can I execute the script in a different way to begin with that gives me the proper control over it?

  • By the way, we Unix & Linux people don't use the phrase "batch file". – Scott Aug 28 '15 at 13:51
  • Nitpicking adhered. – forthrin Aug 28 '15 at 13:57
4

Try running the script as a script instead of sourcing it:

$ bash <scriptname>
  • So simple! Now everything behaves exactly as desired. So when should one use source and bash respectively? – forthrin Aug 31 '15 at 9:47
0

Issue is that ffmpeg catches the SIGINT – signal sent by Ctrl+C – but it is ignored in bash as it does not know if the signal is intended for it as well.

One remedy for this is to add a trap for the signal in the script and handle it locally.

For example add a trap to start of file with commands. Then make it executable and run it, or by
$ bash script_file - not source:

trap 'exit' INT

A more fancy line which abort with message and exit status 130:

trap 'printf "Received SIGINT: Terminating.\n";exit 130' INT

Then:

$ ./file_with_commands

Or a sourcing killer script:

#!/bin/bash

trap 'printf "Received SIGINT: Terminating.\n";exit 130' INT

source "$1"

Then:

$ ./sourcetrap file_with_commands

A simple example script could be:

#!/bin/bash

if [[ $1 = trap ]]; then
    trap 'printf "Received SIGINT: Terminating.\n";exit 130' INT
fi

ping localhost
ping localhost
ping localhost
  • Run without trap: ./script_name
  • With trap: ./script_name trap

Then Ctrl+C to witness the difference.


And again; do not source these scripts from terminal prompt.

  • OK, I know that -- insulates you against the possibility that the next word might begin with -, but is there any reason to use it when you know what the next word is, and it does not begin with -? – Scott Aug 28 '15 at 19:12
  • Also, you should warn the user to disable the SIGINT → exit trap immediately upon termination of the script; otherwise, the next time he types (Ctrl)+(C) at a shell prompt (i.e., when he doesn't have a command running in the foreground), the shell will exit. – Scott Aug 28 '15 at 19:22
  • @Scott: Comment 1: -- no reason. Comment 2: This would, AFAIK, only be an issue if he uses source, which I told not to do. – Runium Aug 30 '15 at 20:15
  • Very interesting! I will experiment with this signal handling! – forthrin Aug 31 '15 at 9:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.