One possibility is that the program catches the Ctrl+C sequence. Check the output of stty -a; the intr setting indicates which key combination (if any) sends a SIGINT signal, and the isig indicates whether the signal keys are enabled (-isig means they are disabled).
If the program consists of several processes, pressing Ctrl+C sends SIGINT to all the processes in the process group. You can obtain the same effect by sending the signal to the process group instead of sending it to one of the processes. To send a signal to a process group, first determine its leader: that's the first process that starts all the others; if you run the process group in the background, that's the PID shown by jobs -l. The PID of the process group leader is the PGID (process group id); send the signal to its negative. E.g. if the PGID is 1234, run kill -INT -1234.
If the program consists of a wrapper script and a main application, there are two cases to consider. If there is no cleanup to do, so that the wrapper script terminates as soon as the main aplication terminates, make the wrapper script call exec:
#!/bin/sh
export SOMEVAR=somevalue
…
exec /path/to/application "$@"
This way the application replaces the script, inheriting its PID. Some shells optimize a script that ends by executing another program, but not all. This approach doesn't work when the script needs to perform some cleanup such as removing temporary files.
Consider making the script detect a signal and transmitting the signal to the application. Here's a sketch of how this goes:
/path/to/application "$@" &
app_pid=$!
trap -INT 'kill -INT $app_pid'
wait $!
rm /temp/file
What makes Ctrl-Z different from kill -STOP, and how can I get the behavior of the former in a shell script?
CTRL-Z usually sends SIGTSTP (which can be blocked), and - apart from other things - shells often reset tty to a previously saved state on these occasions. More importantly however, the controlling terminal process group is set to the shell's PID (and then again to a PID of a job resumed with fg).
Back to your original problem: using a temperature dependent frequency scaling like e.g. Cpufreqd might be actually a better hammer for your nail.
Best Answer
What it does is entirely application specific. When you press ctrl+c, the terminal emulator sends a SIGINT signal to the foreground application, which triggers the appropriate "signal handler". The default signal handler for SIGINT terminates the application. But any program can install its own signal handler for SIGINT (including a signal handler that does not stop the execution at all).
Apparently, vlc installs a signal handler that attempts to do some cleanup / graceful termination upon the first time it is invoked, and falls back to the default behavior of instantly terminating execution when it is invoked for a second time.