where function_name is the function you want to find out its definition. Learned this trick through
While debugging with gdb, one can use the following gdb command to instruct gdb to continue when a SIGPIPE signal is sent to the program being debugged.
(gdb) handle SIGPIPE nostop
Every time when a SIGPIPE command is fired, one will see the following on the gdb console
Program received signal SIGPIPE, Broken pipe.
The nostop gdb command should take care of most of the situations where user interaction is not required. However if the information to be printed by gdb exceeds one screen, the following prompt will appear
---Type <return> to continue, or q <return> to quit---
due to the fact that gdb has pagination on by default, meaning if the erroneous output from gdb exceeds a screen, gdb will ask user for actions.
The reason behind that, I guess, is that gdb doesn’t want the important information to be missed since the top most lines will be scrolled out of the screen (default number lines per screen is 68 in gdb). This is useful when debugging in interactive mode, however it’ll also pause the program. If this is not desired, simply use the following gdb command to turn off pagination:
(gdb) set pagination off
(gdb) set height 0
1) In Perl,
perl -c script.pl
2) In PHP, as I mentioned here,
php -l script.php
3) In Bash,
bash -n script.sh
Yet one can use
ini_set("display_errors", 1); in php scripts to turn on error reporting (which might sometimes output a blank, dont-know-what-goes-wrong web page due to some simple syntax errors), there’s another quick and simple way to find all the syntax errors before even run it for the first time, and that is php command line (assuming that the php CLI is installed):
php -l script_name.php
What it does is checking for any syntax erros in the file script_name.php. I use this technique quite often to examine php scripts before I copy them to the web server.