The ctags utility makes a tags file for ex(1) from the specified C, C++,
Pascal, FORTRAN, yacc(1),
and lex(1) sources. A
tags file gives the locations of specified objects (in this case functions
and typedefs) in a group of files. Each line of the tags file contains the
object name, the file in which it is defined, and an address specification
for the object definition. Functions are searched with a pattern, typedefs
with a line number. Specifiers are given in separate fields on the line, separated
by SPACE or TAB characters. Using the tags
file, ex can quickly find these objects' definitions.
Normally, ctags places the tag descriptions in a
file called tags; this may be overridden with the –f option.
Files with names ending in .c or .h are
assumed to be either C or C++ source files and are searched for C/C++ routine
and macro definitions. Files with names ending in .cc,
.C, or .cxx, are assumed to be C++ source files.
Files with names ending in .y are assumed to be yacc
source files. Files with names ending in .l are
assumed to be lex files. Others are first examined to
see if they contain any Pascal or FORTRAN routine definitions;
if not, they are processed again looking for C definitions.
The tag main is treated specially in C or C++ programs.
The tag formed is created by prepending M to file
, with a trailing .c, .cc
.C, or .cxx removed, if any, and leading path
name components also removed. This makes use of ctags practical
in directories with more than one program.
The precedence of the options that pertain to printing is –x, –
v, then the remaining options. The following options are supported:
Appends output to an existing tags file.
Uses backward searching patterns (?. . .
Places the tag descriptions in a file called tagsfile
instead of tags.
Creates tags for typedefs. /usr/xpg4/bin/ctags creates
tags for typedefs by default.
Updates the specified files in tags, that is, all references
to them are deleted, and the new values are appended to the file. Beware:
this option is implemented in a way that is rather slow; it is usually faster
to simply rebuild the tags file.
Produces on the standard output an index listing the function
name, file name, and page number (assuming 64 line pages). Since the output
will be sorted into lexicographic order, it may be desired to run the output
Suppresses warning diagnostics.
Produces a list of object names, the line number and file
name on which each is defined, as well as the text of that line and prints
this on the standard output. This is a simple index which can be printed out
as an off-line readable function index.
The following file operands are supported:
Files with basenames ending with the .c suffix
are treated as C-language source code.
Files with basenames ending with the .h suffix
are treated as C-language source code.
Files with basenames ending with the .f suffix
are treated as FORTRAN-language source code.
Example 1 Producing entries in alphabetical order
Using ctags with the –v option produces
entries in an order which may not always be appropriate for vgrind.
To produce results in alphabetical order, you may want to run the output through
example% ctags -v filename.c filename.h | sort -f > index
example% vgrind -x index
Example 2 Building a tags file
To build a tags file for C sources in a directory hierarchy rooted at
sourcedir, first create an empty tags file, and then run find(1)
Recognition of functions, subroutines,
and procedures for FORTRAN and Pascal
is done in a very simpleminded way. No attempt is made to deal with block
structure; if you have two Pascal procedures in different blocks with the
same name, you lose.
The method of deciding whether to look for C or Pascal and FORTRAN
functions is a hack.
The ctags utility does not know about #ifdefs.
The ctags utility should know about Pascal types.
Relies on the input being well formed to detect typedefs. Use of –tx shows
only the last line of typedefs.