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 through sort–f.
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 sort–f.
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.