Many systems provide system call tracers, programs that execute target programs, printing out each system call and its arguments as the target program executes them. It is likely you have one on your system; look for one of the following commands: ktrace, par, strace, trace, or truss. While these tools are normally not used inside shell scripts, they can be helpful for finding out what a process is doing and why it is taking so long. Also, they do not require source code access, or any changes whatsoever to the programs to be traced, so you can use them on any process that you own. They can also help your understanding of processes, so we give some small examples later in this section.
If you are unfamiliar with the names of Unix system calls, you can
quickly discover many of them by examination of trace logs. Their
documentation is traditionally found in Section 2 of the online manuals;
e.g., open(2). For example, file-existence tests
usually involve the
access( ) or
stat( ) system calls, and file
deletion requires the
Most compiled programming languages have a debugger that allows
single stepping, setting of breakpoints, examination of variables, and
so on. On most systems, the shells have no debugger, so you sometimes
have to use the shell's
-v option to get shell input
lines printed, and the
-x option to get commands and their arguments printed. System-call tracers can provide a useful supplement to that output, since ...