1CTAGS(1) Exuberant Ctags CTAGS(1)
2
3
4
6 ctags - Generate tag files for source code
7
8
9
11 ctags [options] [file(s)]
12
13 etags [options] [file(s)]
14
15
16
18 The ctags and etags programs (hereinafter collectively referred to as
19 ctags, except where distinguished) generate an index (or "tag") file
20 for a variety of language objects found in file(s). This tag file
21 allows these items to be quickly and easily located by a text editor or
22 other utility. A "tag" signifies a language object for which an index
23 entry is available (or, alternatively, the index entry created for that
24 object).
25
26 Alternatively, ctags can generate a cross reference file which lists,
27 in human readable form, information about the various source objects
28 found in a set of language files.
29
30 Tag index files are supported by numerous editors, which allow the user
31 to locate the object associated with a name appearing in a source file
32 and jump to the file and line which defines the name. Those known about
33 at the time of this release are:
34
35 Vi(1) and its derivatives (e.g. Elvis, Vim, Vile, Lemmy), CRiSP,
36 Emacs, FTE (Folding Text Editor), JED, jEdit, Mined, NEdit (Nirvana
37 Edit), TSE (The SemWare Editor), UltraEdit, WorkSpace, X2, Zeus
38
39 Ctags is capable of generating different kinds of tags for each of many
40 different languages. For a complete list of supported languages, the
41 names by which they are recognized, and the kinds of tags which are
42 generated for each, see the --list-languages and --list-kinds options.
43
44
45
47 Unless the --language-force option is specified, the language of each
48 source file is automatically selected based upon a mapping of file
49 names to languages. The mappings in effect for each language may be
50 display using the --list-maps option and may be changed using the
51 --langmap option. On platforms which support it, if the name of a file
52 is not mapped to a language and the file is executable, the first line
53 of the file is checked to see if the file is a "#!" script for a recog‐
54 nized language.
55
56 By default, all other files names are ignored. This permits running
57 ctags on all files in either a single directory (e.g. "ctags *"), or on
58 all files in an entire source directory tree (e.g. "ctags -R"), since
59 only those files whose names are mapped to languages will be scanned.
60
61 [The reason that .h extensions are mapped to C++ files rather than C
62 files is because it is common to use .h extensions in C++, and no harm
63 results in treating them as C++ files.]
64
65
66
68 Despite the wealth of available options, defaults are set so that ctags
69 is most commonly executed without any options (e.g. "ctags *", or
70 "ctags -R"), which will create a tag file in the current directory for
71 all recognized source files. The options described below are provided
72 merely to allow custom tailoring to meet special needs.
73
74 Note that spaces separating the single-letter options from their param‐
75 eters are optional.
76
77 Note also that the boolean parameters to the long form options (those
78 beginning with "--" and that take a "[=yes|no]" parameter) may be omit‐
79 ted, in which case "=yes" is implied. (e.g. --sort is equivalent to
80 --sort=yes). Note further that "=1" and "=on" are considered synonyms
81 for "=yes", and that "=0" and "=off" are considered synonyms for "=no".
82
83 Some options are either ignored or useful only when used while running
84 in etags mode (see -e option). Such options will be noted.
85
86 Most options may appear anywhere on the command line, affecting only
87 those files which follow the option. A few options, however, must
88 appear before the first file name and will be noted as such.
89
90 Options taking language names will accept those names in either upper
91 or lower case. See the --list-languages option for a complete list of
92 the built-in language names.
93
94
95 -a Equivalent to --append.
96
97
98 -B Use backward searching patterns (e.g. ?pattern?). [Ignored in
99 etags mode]
100
101
102 -e Enable etags mode, which will create a tag file for use with the
103 Emacs editor. Alternatively, if ctags is invoked by a name con‐
104 taining the string "etags" (either by renaming, or creating a link
105 to, the executable), etags mode will be enabled. This option must
106 appear before the first file name.
107
108
109 -f tagfile
110 Use the name specified by tagfile for the tag file (default is
111 "tags", or "TAGS" when running in etags mode). If tagfile is spec‐
112 ified as "-", then the tag file is written to standard output
113 instead. Ctags will stubbornly refuse to take orders if tagfile
114 exists and its first line contains something other than a valid
115 tags line. This will save your neck if you mistakenly type "ctags
116 -f *.c", which would otherwise overwrite your first C file with
117 the tags generated by the rest! It will also refuse to accept a
118 multi character file name which begins with a '-' (dash) charac‐
119 ter, since this most likely means that you left out the tag file
120 name and this option tried to grab the next option as the file
121 name. If you really want to name your output tag file "-ugly",
122 specify it as "./-ugly". This option must appear before the first
123 file name. If this option is specified more than once, only the
124 last will apply.
125
126
127 -F Use forward searching patterns (e.g. /pattern/) (default).
128 [Ignored in etags mode]
129
130
131 -h list
132 Specifies a list of file extensions, separated by periods, which
133 are to be interpreted as include (or header) files. To indicate
134 files having no extension, use a period not followed by a non-
135 period character (e.g. ".", "..x", ".x."). This option only
136 affects how the scoping of a particular kinds of tags is inter‐
137 preted (i.e. whether or not they are considered as globally visi‐
138 ble or visible only within the file in which they are defined); it
139 does not map the extension to any particular language. Any tag
140 which is located in a non-include file and cannot be seen (e.g.
141 linked to) from another file is considered to have file-limited
142 (e.g. static) scope. No kind of tag appearing in an include file
143 will be considered to have file-limited scope. If the first char‐
144 acter in the list is a plus sign, then the extensions in the list
145 will be appended to the current list; otherwise, the list will
146 replace the current list. See, also, the --file-scope option. The
147 default list is ".h.H.hh.hpp.hxx.h++.inc.def". To restore the
148 default list, specify -h default. Note that if an extension sup‐
149 plied to this option is not already mapped to a particular lan‐
150 guage (see SOURCE FILES, above), you will also need to use either
151 the --langmap or --language-force option.
152
153
154 -I identifier-list
155 Specifies a list of identifiers which are to be specially handled
156 while parsing C and C++ source files. This option is specifically
157 provided to handle special cases arising through the use of pre‐
158 processor macros. When the identifiers listed are simple identi‐
159 fiers, these identifiers will be ignored during parsing of the
160 source files. If an identifier is suffixed with a '+' character,
161 ctags will also ignore any parenthesis-enclosed argument list
162 which may immediately follow the identifier in the source files.
163 If two identifiers are separated with the '=' character, the first
164 identifiers is replaced by the second identifiers for parsing pur‐
165 poses. The list of identifiers may be supplied directly on the
166 command line or read in from a separate file. If the first charac‐
167 ter of identifier-list is '@', '.' or a pathname separator ('/' or
168 '\'), or the first two characters specify a drive letter (e.g.
169 "C:"), the parameter identifier-list will be interpreted as a
170 filename from which to read a list of identifiers, one per input
171 line. Otherwise, identifier-list is a list of identifiers (or
172 identifier pairs) to be specially handled, each delimited by a
173 either a comma or by white space (in which case the list should be
174 quoted to keep the entire list as one command line argument). Mul‐
175 tiple -I options may be supplied. To clear the list of ignore
176 identifiers, supply a single dash ("-") for identifier-list.
177
178 This feature is useful when preprocessor macros are used in such a
179 way that they cause syntactic confusion due to their presence.
180 Indeed, this is the best way of working around a number of prob‐
181 lems caused by the presence of syntax-busting macros in source
182 files (see CAVEATS, below). Some examples will illustrate this
183 point.
184
185 int foo ARGDECL4(void *, ptr, long int, nbytes)
186
187
188 In the above example, the macro "ARGDECL4" would be mistakenly
189 interpreted to be the name of the function instead of the correct
190 name of "foo". Specifying -I ARGDECL4 results in the correct
191 behavior.
192
193 /* creates an RCS version string in module */
194 MODULE_VERSION("$Revision: 1.41 $")
195
196
197 In the above example the macro invocation looks too much like a
198 function definition because it is not followed by a semicolon
199 (indeed, it could even be followed by a global variable definition
200 that would look much like a K&R style function parameter declara‐
201 tion). In fact, this seeming function definition could possibly
202 even cause the rest of the file to be skipped over while trying to
203 complete the definition. Specifying -I MODULE_VERSION+ would avoid
204 such a problem.
205
206 CLASS Example {
207 // your content here
208 };
209
210
211 The example above uses "CLASS" as a preprocessor macro which
212 expands to something different for each platform. For instance
213 CLASS may be defined as "class __declspec(dllexport)" on Win32
214 platforms and simply "class" on UNIX. Normally, the absence of
215 the C++ keyword "class" would cause the source file to be incor‐
216 rectly parsed. Correct behavior can be restored by specifying -I
217 CLASS=class.
218
219
220 -L file
221 Read from file a list of file names for which tags should be gen‐
222 erated. If file is specified as "-", then file names are read
223 from standard input. File names read using this option are pro‐
224 cessed following file names appearing on the command line. Options
225 all also accepted in this input. If this option is specified more
226 than once, only the last will apply. Note: file is read in line-
227 oriented mode, where a new line is the only delimiter and spaces
228 are considered significant, in order that file names containing
229 spaces may be supplied; this can affect how options are parsed if
230 included in the input.
231
232
233 -n Equivalent to --excmd=number.
234
235
236 -N Equivalent to --excmd=pattern.
237
238
239 -o tagfile
240 Equivalent to -f tagfile.
241
242
243 -R Equivalent to --recurse.
244
245
246 -u Equivalent to --sort=no (i.e. "unsorted").
247
248
249 -V Equivalent to --verbose.
250
251
252 -w This option is silently ignored for backward-compatibility with
253 the ctags of SVR4 Unix.
254
255
256 -x Print a tabular, human-readable cross reference (xref) file to
257 standard output instead of generating a tag file. The information
258 contained in the output includes: the tag name; the kind of tag;
259 the line number, file name, and source line (with extra white
260 space condensed) of the file which defines the tag. No tag file is
261 written and all options affecting tag file output will be ignored.
262 Example applications for this feature are generating a listing of
263 all functions located in a source file (e.g. ctags -x --c-kinds=f
264 file), or generating a list of all externally visible global vari‐
265 ables located in a source file (e.g. ctags -x --c-kinds=v --file-
266 scope=no file). This option must appear before the first file
267 name.
268
269
270 --append[=yes|no]
271 Indicates whether tags generated from the specified files should
272 be appended to those already present in the tag file or should
273 replace them. This option is off by default. This option must
274 appear before the first file name.
275
276
277 --etags-include=file
278 Include a reference to file in the tag file. This option may be
279 specified as many times as desired. This supports Emacs' capabil‐
280 ity to use a tag file which "includes" other tag files. [Available
281 only in etags mode]
282
283
284 --exclude=[pattern]
285 Add pattern to a list of excluded files and directories. This
286 option may be specified as many times as desired. For each file
287 name considered by ctags, each pattern specified using this option
288 will be compared against both the complete path (e.g.
289 some/path/base.ext) and the base name (e.g. base.ext) of the file,
290 thus allowing patterns which match a given file name irrespective
291 of its path, or match only a specific path. If appropriate support
292 is available from the runtime library of your C compiler, then
293 pattern may contain the usual shell wildcards (not regular expres‐
294 sions) common on Unix (be sure to quote the option parameter to
295 protect the wildcards from being expanded by the shell before
296 being passed to ctags; also be aware that wildcards can match the
297 slash character, '/'). You can determine if shell wildcards are
298 available on your platform by examining the output of the --ver‐
299 sion option, which will include "+wildcards" in the compiled fea‐
300 ture list; otherwise, pattern is matched against file names using
301 a simple textual comparison.
302
303 If pattern begins with the character '@', then the rest of the
304 string is interpreted as a file name from which to read exclusion
305 patterns, one per line. If pattern is empty, the list of excluded
306 patterns is cleared. Note that at program startup, the default
307 exclude list contains "EIFGEN", "SCCS", "RCS", and "CVS", which
308 are names of directories for which it is generally not desirable
309 to descend while processing the --recurse option.
310
311
312 --excmd=type
313 Determines the type of EX command used to locate tags in the
314 source file. [Ignored in etags mode]
315
316 The valid values for type (either the entire word or the first
317 letter is accepted) are:
318
319
320 number Use only line numbers in the tag file for locating tags.
321 This has four advantages:
322 1. Significantly reduces the size of the resulting tag
323 file.
324 2. Eliminates failures to find tags because the line
325 defining the tag has changed, causing the pattern
326 match to fail (note that some editors, such as vim,
327 are able to recover in many such instances).
328 3. Eliminates finding identical matching, but incorrect,
329 source lines (see BUGS, below).
330 4. Retains separate entries in the tag file for lines
331 which are identical in content. In pattern mode,
332 duplicate entries are dropped because the search pat‐
333 terns they generate are identical, making the dupli‐
334 cate entries useless.
335
336
337 However, this option has one significant drawback:
338 changes to the source files can cause the line numbers
339 recorded in the tag file to no longer correspond to the
340 lines in the source file, causing jumps to some tags to
341 miss the target definition by one or more lines. Basi‐
342 cally, this option is best used when the source code to
343 which it is applied is not subject to change. Selecting
344 this option type causes the following options to be
345 ignored: -BF.
346
347
348 pattern Use only search patterns for all tags, rather than the
349 line numbers usually used for macro definitions. This has
350 the advantage of not referencing obsolete line numbers
351 when lines have been added or removed since the tag file
352 was generated.
353
354
355 mixed In this mode, patterns are generally used with a few
356 exceptions. For C, line numbers are used for macro defi‐
357 nition tags. This was the default format generated by the
358 original ctags and is, therefore, retained as the default
359 for this option. For Fortran, line numbers are used for
360 common blocks because their corresponding source lines
361 are generally identical, making pattern searches useless
362 for finding all matches.
363
364
365 --extra=[+|-]flags
366 Specifies whether to include extra tag entries for certain kinds
367 of information. The parameter flags is a set of one-letter flags,
368 each representing one kind of extra tag entry to include in the
369 tag file. If flags is preceded by by either the '+' or '-' charac‐
370 ter, the effect of each flag is added to, or removed from, those
371 currently enabled; otherwise the flags replace any current set‐
372 tings. The meaning of each flag is as follows:
373
374
375 f Include an entry for the base file name of every source
376 file (e.g. "example.c"), which addresses the first line of
377 the file.
378
379 q Include an extra class-qualified tag entry for each tag
380 which is a member of a class (for languages for which this
381 information is extracted; currently C++, Eiffel, and Java).
382 The actual form of the qualified tag depends upon the lan‐
383 guage from which the tag was derived (using a form that is
384 most natural for how qualified calls are specified in the
385 language). For C++, it is in the form "class::member"; for
386 Eiffel and Java, it is in the form "class.member". This may
387 allow easier location of a specific tags when multiple
388 occurrences of a tag name occur in the tag file. Note, how‐
389 ever, that this could potentially more than double the size
390 of the tag file.
391
392
393 --fields=[+|-]flags
394 Specifies the available extension fields which are to be included
395 in the entries of the tag file (see TAG FILE FORMAT, below, for
396 more information). The parameter flags is a set of one-letter
397 flags, each representing one type of extension field to include,
398 with the following meanings (disabled by default unless indi‐
399 cated):
400
401
402 a Access (or export) of class members
403 f File-restricted scoping [enabled]
404 i Inheritance information
405 k Kind of tag as a single letter [enabled]
406 K Kind of tag as full name
407 l Language of source file containing tag
408 m Implementation information
409 n Line number of tag definition
410 s Scope of tag definition [enabled]
411 S Signature of routine (e.g. prototype or parameter list)
412 z Include the "kind:" key in kind field
413 t Type and name of a variable or typedef as "typeref:" field
414 [enabled]
415
416 Each letter or group of letters may be preceded by either '+' to
417 add it to the default set, or '-' to exclude it. In the absence of
418 any preceding '+' or '-' sign, only those kinds explicitly listed
419 in flags will be included in the output (i.e. overriding the
420 default set). This option is ignored if the option --format=1 has
421 been specified. The default value of this options is fks.
422
423
424 --file-scope[=yes|no]
425 Indicates whether tags scoped only for a single file (i.e. tags
426 which cannot be seen outside of the file in which they are
427 defined, such as "static" tags) should be included in the output.
428 See, also, the -h option. This option is enabled by default.
429
430
431 --filter[=yes|no]
432 Causes ctags to behave as a filter, reading source file names from
433 standard input and printing their tags to standard output on a
434 file-by-file basis. If --sorted is enabled, tags are sorted only
435 within the source file in which they are defined. File names are
436 read from standard output in line-oriented input mode (see note
437 for -L option) and only after file names listed on the command
438 line or from any file supplied using the -L option. When this
439 option is enabled, the options -f, -o, and --totals are ignored.
440 This option is quite esoteric and is disabled by default. This
441 option must appear before the first file name.
442
443
444 --filter-terminator=string
445 Specifies a string to print to standard output following the tags
446 for each file name parsed when the --filter option is enabled.
447 This may permit an application reading the output of ctags to
448 determine when the output for each file is finished. Note that if
449 the file name read is a directory and --recurse is enabled, this
450 string will be printed only one once at the end of all tags found
451 for by descending the directory. This string will always be sepa‐
452 rated from the last tag line for the file by its terminating new‐
453 line. This option is quite esoteric and is empty by default. This
454 option must appear before the first file name.
455
456
457 --format=level
458 Change the format of the output tag file. Currently the only valid
459 values for level are 1 or 2. Level 1 specifies the original tag
460 file format and level 2 specifies a new extended format containing
461 extension fields (but in a manner which retains backward-compati‐
462 bility with original vi(1) implementations). The default level is
463 2. This option must appear before the first file name. [Ignored in
464 etags mode]
465
466
467 --help
468 Prints to standard output a detailed usage description, and then
469 exits.
470
471
472 --if0[=yes|no]
473 Indicates a preference as to whether code within an "#if 0" branch
474 of a preprocessor conditional should be examined for non-macro
475 tags (macro tags are always included). Because the intent of this
476 construct is to disable code, the default value of this options is
477 no. Note that this indicates a preference only and does not guar‐
478 antee skipping code within an "#if 0" branch, since the fall-back
479 algorithm used to generate tags when preprocessor conditionals are
480 too complex follows all branches of a conditional. This option is
481 disabled by default.
482
483
484 --<LANG>-kinds=[+|-]kinds
485 Specifies a list of language-specific kinds of tags (or kinds) to
486 include in the output file for a particular language, where <LANG>
487 is case-insensitive and is one of the built-in language names (see
488 the --list-languages option for a complete list). The parameter
489 kinds is a group of one-letter flags designating kinds of tags
490 (particular to the language) to either include or exclude from the
491 output. The specific sets of flags recognized for each language,
492 their meanings and defaults may be list using the --list-kinds
493 option. Each letter or group of letters may be preceded by either
494 '+' to add it to, or '-' to remove it from, the default set. In
495 the absence of any preceding '+' or '-' sign, only those kinds
496 explicitly listed in kinds will be included in the output (i.e.
497 overriding the default for the specified language).
498
499 As an example for the C language, in order to add prototypes and
500 external variable declarations to the default set of tag kinds,
501 but exclude macros, use --c-kinds=+px-d; to include only tags for
502 functions, use --c-kinds=f.
503
504
505 --langdef=name
506 Defines a new user-defined language, name, to be parsed with regu‐
507 lar expressions. Once defined, name may be used in other options
508 taking language names. The typical use of this option is to first
509 define the language, then map file names to it using --langmap,
510 then specify regular expressions using --regex-<LANG> to define
511 how its tags are found.
512
513
514 --langmap=map[,map[...]]
515 Controls how file names are mapped to languages (see the --list-
516 maps option). Each comma-separated map consists of the language
517 name (either a built-in or user-defined language), a colon, and a
518 list of file extensions and/or file name patterns. A file exten‐
519 sion is specified by preceding the extension with a period (e.g.
520 ".c"). A file name pattern is specified by enclosing the pattern
521 in parentheses (e.g. "([Mm]akefile)"). If appropriate support is
522 available from the runtime library of your C compiler, then the
523 file name pattern may contain the usual shell wildcards common on
524 Unix (be sure to quote the option parameter to protect the wild‐
525 cards from being expanded by the shell before being passed to
526 ctags). You can determine if shell wildcards are available on your
527 platform by examining the output of the --version option, which
528 will include "+wildcards" in the compiled feature list; otherwise,
529 the file name patterns are matched against file names using a sim‐
530 ple textual comparison. When mapping a file extension, it will
531 first be unmapped from any other languages.
532
533 If the first character in a map is a plus sign, then the exten‐
534 sions and file name patterns in that map will be appended to the
535 current map for that language; otherwise, the map will replace the
536 current map. For example, to specify that only files with exten‐
537 sions of .c and .x are to be treated as C language files, use
538 "--langmap=c:.c.x"; to also add files with extensions of .j as
539 Java language files, specify "--langmap=c:.c.x,java:+.j". To map
540 makefiles (.e.g files named either "Makefile", "makefile", or hav‐
541 ing the extension ".mak") to a language called "make", specify
542 "--langmap=make:([Mm]akefile).mak". To map files having no exten‐
543 sion, specify a period not followed by a non-period character
544 (e.g. ".", "..x", ".x."). To clear the mapping for a particular
545 language (thus inhibiting automatic generation of tags for that
546 language), specify an empty extension list (e.g. "--langmap=for‐
547 tran:"). To restore the default language mappings for all a par‐
548 ticular language, supply the keyword "default" for the mapping.
549 To specify restore the default language mappings for all lan‐
550 guages, specify "--langmap=default". Note that file extensions are
551 tested before file name patterns when inferring the language of a
552 file.
553
554
555 --language-force=language
556 By default, ctags automatically selects the language of a source
557 file, ignoring those files whose language cannot be determined
558 (see SOURCE FILES, above). This option forces the specified lan‐
559 guage (case-insensitive; either built-in or user-defined) to be
560 used for every supplied file instead of automatically selecting
561 the language based upon its extension. In addition, the special
562 value auto indicates that the language should be automatically
563 selected (which effectively disables this option).
564
565
566 --languages=[+|-]list
567 Specifies the languages for which tag generation is enabled, with
568 list containing a comma-separated list of language names (case-
569 insensitive; either built-in or user-defined). If the first lan‐
570 guage of list is not preceded by either a '+' or '-', the current
571 list will be cleared before adding or removing the languages in
572 list. Until a '-' is encountered, each language in the list will
573 be added to the current list. As either the '+' or removed from
574 the current list, respectively. Thus, it becomes simple to replace
575 the current list with a new one, or to add or remove languages
576 from the current list. The actual list of files for which tags
577 will be generated depends upon the language extension mapping in
578 effect (see the --langmap option). Note that all languages,
579 including user-defined languages are enabled unless explicitly
580 disabled using this option. Language names included in list may be
581 any built-in language or one previously defined with --langdef.
582 The default is "all", which is also accepted as a valid argument.
583 See the --list-languages option for a complete list of the built-
584 in language names.
585
586
587 --license
588 Prints a summary of the software license to standard output, and
589 then exits.
590
591
592 --line-directives[=yes|no]
593 Specifies whether "#line" directives should be recognized. These
594 are present in the output of preprocessors and contain the line
595 number, and possibly the file name, of the original source file(s)
596 from which the preprocessor output file was generated. When
597 enabled, this option will cause ctags to generate tag entries
598 marked with the file names and line numbers of their locations
599 original source file(s), instead of their actual locations in the
600 preprocessor output. The actual file names placed into the tag
601 file will have the same leading path components as the preproces‐
602 sor output file, since it is assumed that the original source
603 files are located relative to the preprocessor output file
604 (unless, of course, the #line directive specifies an absolute
605 path). This option is off by default. Note: This option is gener‐
606 ally only useful when used together with the --excmd=number (-n)
607 option. Also, you may have to use either the --langmap or --lan‐
608 guage-force option if the extension of the preprocessor output
609 file is not known to ctags.
610
611
612 --links[=yes|no]
613 Indicates whether symbolic links (if supported) should be fol‐
614 lowed. When disabled, symbolic links are ignored. This option is
615 on by default.
616
617
618 --list-kinds[=language|all]
619 Lists the tag kinds recognized for either the specified language
620 or all languages, and then exits. Each kind of tag recorded in the
621 tag file is represented by a one-letter flag, which is also used
622 to filter the tags placed into the output through use of the
623 --<LANG>-kinds option. Note that some languages and/or tag kinds
624 may be implemented using regular expressions and may not be avail‐
625 able if regex support is not compiled into ctags (see the
626 --regex-<LANG> option). Each kind listed is enabled unless fol‐
627 lowed by "[off]".
628
629
630 --list-maps[=language|all]
631 Lists the file extensions and file name patterns which associate a
632 file name with a language for either the specified language or all
633 languages, and then exits. See the --langmap option, and SOURCE
634 FILES, above.
635
636
637 --list-languages
638 Lists the names of the languages understood by ctags, and then
639 exits. These language names are case insensitive and may be used
640 in the --language-force, --languages, --<LANG>-kinds, and
641 --regex-<LANG> options.
642
643
644 --options=file
645 Read additional options from file. As a special case, if
646 --options=NONE is specified as the first option on the command
647 line, it will disable the automatic reading of any configuration
648 options from either a file or the environment (see FILES).
649
650
651 --recurse[=yes|no]
652 Recurse into directories encountered in the list of supplied
653 files. If the list of supplied files is empty and no file list is
654 specified with the -L option, then the current directory (i.e.
655 ".") is assumed. Symbolic links are followed. If you don't like
656 these behaviors, either explicitly specify the files or pipe the
657 output of find(1) into ctags -L- instead. Note: This option is not
658 supported on all platforms at present. It is available if the
659 output of the --help option includes this option. See, also, the
660 --exclude to limit recursion.
661
662
663 --regex-<LANG>=/regexp/replacement/[kind-spec/][flags]
664 The /regexp/replacement/ pair define a regular expression replace‐
665 ment pattern, similar in style to sed substitution commands, with
666 which to generate tags from source files mapped to the named lan‐
667 guage, <LANG>, (case-insensitive; either a built-in or user-
668 defined language). The regular expression, regexp, defines an
669 extended regular expression (roughly that used by egrep(1)), which
670 is used to locate a single source line containing a tag and may
671 specify tab characters using \t. When a matching line is found, a
672 tag will be generated for the name defined by replacement, which
673 generally will contain the special back-references \1 through \9
674 to refer to matching sub-expression groups within regexp. The '/'
675 separator characters shown in the parameter to the option can
676 actually be replaced by any character. Note that whichever separa‐
677 tor character is used will have to be escaped with a backslash
678 ('\') character wherever it is used in the parameter as something
679 other than a separator. The regular expression defined by this
680 option is added to the current list of regular expressions for the
681 specified language unless the parameter is omitted, in which case
682 the current list is cleared.
683
684 Unless modified by flags, regexp is interpreted as a Posix
685 extended regular expression. The replacement should expand for all
686 matching lines to a non-empty string of characters, or a warning
687 message will be reported. An optional kind specifier for tags
688 matching regexp may follow replacement, which will determine what
689 kind of tag is reported in the "kind" extension field (see TAG
690 FILE FORMAT, below). The full form of kind-spec is in the form of
691 a single letter, a comma, a name (without spaces), a comma, a
692 description, followed by a separator, which specify the short and
693 long forms of the kind value and its textual description (dis‐
694 played using --list-kinds). Either the kind name and/or the
695 description may be omitted. If kind-spec is omitted, it defaults
696 to "r,regex". Finally, flags are one or more single-letter charac‐
697 ters having the following effect upon the interpretation of reg‐
698 exp:
699
700
701 b The pattern is interpreted as a Posix basic regular expres‐
702 sion.
703
704 e The pattern is interpreted as a Posix extended regular
705 expression (default).
706
707 i The regular expression is to be applied in a case-insensi‐
708 tive manner.
709
710 Note that this option is available only if ctags was compiled with
711 support for regular expressions, which depends upon your platform.
712 You can determine if support for regular expressions is compiled
713 in by examining the output of the --version option, which will
714 include "+regex" in the compiled feature list.
715
716 For more information on the regular expressions used by ctags, see
717 either the regex(5,7) man page, or the GNU info documentation for
718 regex (e.g. "info regex").
719
720
721 --sort[=yes|no|foldcase]
722 Indicates whether the tag file should be sorted on the tag name
723 (default is yes). Note that the original vi(1) required sorted
724 tags. The foldcase value specifies case insensitive (or case-
725 folded) sorting. Fast binary searches of tag files sorted with
726 case-folding will require special support from tools using tag
727 files, such as that found in the ctags readtags library, or Vim
728 version 6.2 or higher (using "set ignorecase"). This option must
729 appear before the first file name. [Ignored in etags mode]
730
731
732 --tag-relative[=yes|no]
733 Indicates that the file paths recorded in the tag file should be
734 relative to the directory containing the tag file, rather than
735 relative to the current directory, unless the files supplied on
736 the command line are specified with absolute paths. This option
737 must appear before the first file name. The default is yes when
738 running in etags mode (see the -e option), no otherwise.
739
740
741 --totals[=yes|no]
742 Prints statistics about the source files read and the tag file
743 written during the current invocation of ctags. This option is off
744 by default. This option must appear before the first file name.
745
746
747 --verbose[=yes|no]
748 Enable verbose mode. This prints out information on option pro‐
749 cessing and a brief message describing what action is being taken
750 for each file considered by ctags. Normally, ctags does not read
751 command line arguments until after options are read from the con‐
752 figuration files (see FILES, below) and the CTAGS environment
753 variable. However, if this option is the first argument on the
754 command line, it will take effect before any options are read from
755 these sources. The default is no.
756
757
758 --version
759 Prints a version identifier for ctags to standard output, and then
760 exits. This is guaranteed to always contain the string "Exuberant
761 Ctags".
762
763
764
766 As ctags considers each file name in turn, it tries to determine the
767 language of the file by applying the following three tests in order: if
768 the file extension has been mapped to a language, if the file name
769 matches a shell pattern mapped to a language, and finally if the file
770 is executable and its first line specifies an interpreter using the
771 Unix-style "#!" specification (if supported on the platform). If a lan‐
772 guage was identified, the file is opened and then the appropriate lan‐
773 guage parser is called to operate on the currently open file. The
774 parser parses through the file and adds an entry to the tag file for
775 each language object it is written to handle. See TAG FILE FORMAT,
776 below, for details on these entries.
777
778 This implementation of ctags imposes no formatting requirements on C
779 code as do legacy implementations. Older implementations of ctags
780 tended to rely upon certain formatting assumptions in order to help it
781 resolve coding dilemmas caused by preprocessor conditionals.
782
783 In general, ctags tries to be smart about conditional preprocessor
784 directives. If a preprocessor conditional is encountered within a
785 statement which defines a tag, ctags follows only the first branch of
786 that conditional (except in the special case of "#if 0", in which case
787 it follows only the last branch). The reason for this is that failing
788 to pursue only one branch can result in ambiguous syntax, as in the
789 following example:
790
791 #ifdef TWO_ALTERNATIVES
792 struct {
793 #else
794 union {
795 #endif
796 short a;
797 long b;
798 }
799
800 Both branches cannot be followed, or braces become unbalanced and ctags
801 would be unable to make sense of the syntax.
802
803 If the application of this heuristic fails to properly parse a file,
804 generally due to complicated and inconsistent pairing within the condi‐
805 tionals, ctags will retry the file using a different heuristic which
806 does not selectively follow conditional preprocessor branches, but
807 instead falls back to relying upon a closing brace ("}") in column 1 as
808 indicating the end of a block once any brace imbalance results from
809 following a #if conditional branch.
810
811 Ctags will also try to specially handle arguments lists enclosed in
812 double sets of parentheses in order to accept the following conditional
813 construct:
814
815 extern void foo __ARGS((int one, char two));
816
817 Any name immediately preceding the "((" will be automatically ignored
818 and the previous name will be used.
819
820 C++ operator definitions are specially handled. In order for consis‐
821 tency with all types of operators (overloaded and conversion), the
822 operator name in the tag file will always be preceded by the string
823 "operator " (i.e. even if the actual operator definition was written as
824 "operator<<").
825
826 After creating or appending to the tag file, it is sorted by the tag
827 name, removing identical tag lines.
828
829
830
832 When not running in etags mode, each entry in the tag file consists of
833 a separate line, each looking like this in the most general case:
834
835 tag_name<TAB>file_name<TAB>ex_cmd;"<TAB>extension_fields
836
837 The fields and separators of these lines are specified as follows:
838
839 1. tag name
840 2. single tab character
841 3. name of the file in which the object associated with the tag is
842 located
843 4. single tab character
844 5. EX command used to locate the tag within the file; generally a
845 search pattern (either /pattern/ or ?pattern?) or line number
846 (see --excmd). Tag file format 2 (see --format) extends this EX
847 command under certain circumstances to include a set of exten‐
848 sion fields (described below) embedded in an EX comment immedi‐
849 ately appended to the EX command, which leaves it backward-com‐
850 patible with original vi(1) implementations.
851
852 A few special tags are written into the tag file for internal purposes.
853 These tags are composed in such a way that they always sort to the top
854 of the file. Therefore, the first two characters of these tags are
855 used a magic number to detect a tag file for purposes of determining
856 whether a valid tag file is being overwritten rather than a source
857 file.
858
859 Note that the name of each source file will be recorded in the tag file
860 exactly as it appears on the command line. Therefore, if the path you
861 specified on the command line was relative to the current directory,
862 then it will be recorded in that same manner in the tag file. See, how‐
863 ever, the --tag-relative option for how this behavior can be modified.
864
865 Extension fields are tab-separated key-value pairs appended to the end
866 of the EX command as a comment, as described above. These key value
867 pairs appear in the general form "key:value". Their presence in the
868 lines of the tag file are controlled by the --fields option. The possi‐
869 ble keys and the meaning of their values are as follows:
870
871
872 access Indicates the visibility of this class member, where value
873 is specific to the language.
874
875
876 file Indicates that the tag has file-limited visibility. This
877 key has no corresponding value.
878
879
880 kind Indicates the type, or kind, of tag. Its value is either
881 one of the corresponding one-letter flags described under
882 the various --<LANG>-kinds options above, or a full name.
883 It is permitted (and is, in fact, the default) for the key
884 portion of this field to be omitted. The optional behaviors
885 are controlled with the --fields option.
886
887
888 implementation
889 When present, this indicates a limited implementation
890 (abstract vs. concrete) of a routine or class, where value
891 is specific to the language ("virtual" or "pure virtual"
892 for C++; "abstract" for Java).
893
894
895 inherits When present, value. is a comma-separated list of classes
896 from which this class is derived (i.e. inherits from).
897
898
899 signature When present, value. is a language-dependent representation
900 of the signature of a routine. A routine signature in its
901 complete form specifies the return type of a routine and
902 its formal argument list. This extension field is presently
903 supported only for C-based languages and does not include
904 the return type.
905
906
907 In addition, information on the scope of the tag definition may be
908 available, with the key portion equal to some language-dependent con‐
909 struct name and its value the name declared for that construct in the
910 program. This scope entry indicates the scope in which the tag was
911 found. For example, a tag generated for a C structure member would have
912 a scope looking like "struct:myStruct".
913
914
915
917 Vi will, by default, expect a tag file by the name "tags" in the cur‐
918 rent directory. Once the tag file is built, the following commands
919 exercise the tag indexing feature:
920
921 vi -t tag Start vi and position the cursor at the file and line where
922 "tag" is defined.
923
924 :ta tag Find a tag.
925
926 Ctrl-] Find the tag under the cursor.
927
928 Ctrl-T Return to previous location before jump to tag (not widely
929 implemented).
930
931
932
934 Emacs will, by default, expect a tag file by the name "TAGS" in the
935 current directory. Once the tag file is built, the following commands
936 exercise the tag indexing feature:
937
938 M-x visit-tags-table <RET> FILE <RET>
939 Select the tag file, "FILE", to use.
940
941 M-. [TAG] <RET>
942 Find the first definition of TAG. The default tag is the
943 identifier under the cursor.
944
945 M-* Pop back to where you previously invoked "M-.".
946
947 C-u M-. Find the next definition for the last tag.
948
949
950 For more commands, see the Tags topic in the Emacs info document.
951
952
953
955 NEdit version 5.1 and later can handle the new extended tag file format
956 (see --format). To make NEdit use the tag file, select "File->Load Tags
957 File". To jump to the definition for a tag, highlight the word, the
958 press Ctrl-D. NEdit 5.1 can can read multiple tag files from different
959 directories. Setting the X resource nedit.tagFile to the name of a tag
960 file instructs NEdit to automatically load that tag file at startup
961 time.
962
963
964
966 Because ctags is neither a preprocessor nor a compiler, use of pre‐
967 processor macros can fool ctags into either missing tags or improperly
968 generating inappropriate tags. Although ctags has been designed to han‐
969 dle certain common cases, this is the single biggest cause of reported
970 problems. In particular, the use of preprocessor constructs which alter
971 the textual syntax of C can fool ctags. You can work around many such
972 problems by using the -I option.
973
974 White space is treated as a separator for file names and options read
975 from list files, specified using the -L option, and in filter mode
976 (specified using the --filter option). Therefore, it is not currently
977 possible to supply file names or other options containing embedded
978 white space (spaces, etc.) through these options.
979
980 Note that when ctags generates uses patterns for locating tags (see the
981 --excmd option), it is entirely possible that the wrong line may be
982 found by your editor if there exists another source line which is iden‐
983 tical to the line containing the tag. The following example demon‐
984 strates this condition:
985
986 int variable;
987
988 /* ... */
989 void foo(variable)
990 int variable;
991 {
992 /* ... */
993 }
994
995 Depending upon which editor you use and where in the code you happen to
996 be, it is possible that the search pattern may locate the local parame‐
997 ter declaration in foo() before it finds the actual global variable
998 definition, since the lines (and therefore their search patterns are
999 identical). This can be avoided by use of the --excmd=n option.
1000
1001
1002
1004 Ctags has more options than ls(1).
1005
1006 When parsing a C++ member function definition (e.g. "className::func‐
1007 tion"), ctags cannot determine whether the scope specifier is a class
1008 name or a namespace specifier and always lists it as a class name in
1009 the scope portion of the extension fields. Also, if a C++ function is
1010 defined outside of the class declaration (the usual case), the access
1011 specification (i.e. public, protected, or private) and implementation
1012 information (e.g. virtual, pure virtual) contained in the function dec‐
1013 laration are not known when the tag is generated for the function defi‐
1014 nition. It will, however be available for prototypes (e.g
1015 --c++-kinds=+p).
1016
1017 No qualified tags are generated for language objects inherited into a
1018 class.
1019
1020
1021
1023 CTAGS If this environment variable exists, it will be expected to
1024 contain a set of default options which are read when ctags
1025 starts, after the configuration files listed in FILES, below,
1026 are read, but before any command line options are read. Options
1027 appearing on the command line will override options specified
1028 in this variable. Only options will be read from this variable.
1029 Note that all white space in this variable in considered a sep‐
1030 arator, making it impossible to pass an option parameter con‐
1031 taining an embedded space. If this is a problem, use a configu‐
1032 ration file instead.
1033
1034
1035 ETAGS Similar to the CTAGS variable above, this variable, if found,
1036 will be read when etags starts. If this variable is not found,
1037 etags will try to use CTAGS instead.
1038
1039
1040 TMPDIR On Unix-like hosts where mkstemp() is available, the value of
1041 this variable specifies the directory in which to place tempo‐
1042 rary files. This can be useful if the size of a temporary file
1043 becomes too large to fit on the partition holding the default
1044 temporary directory defined at compilation time. ctags creates
1045 temporary files only if either (1) an emacs-style tag file is
1046 being generated, (2) the tag file is being sent to standard
1047 output, or (3) the program was compiled to use an internal sort
1048 algorithm to sort the tag files instead of the the sort utility
1049 of the operating system. If the sort utility of the operating
1050 system is being used, it will generally observe this variable
1051 also. Note that if ctags is setuid, the value of TMPDIR will be
1052 ignored.
1053
1054
1055
1057 /ctags.cnf (on MSDOS, MSWindows only)
1058 /etc/ctags.conf
1059 /usr/local/etc/ctags.conf
1060 $HOME/.ctags ($HOME/ctags.cnf on MSDOS, MSWindows)
1061 .ctags (ctags.cnf on MSDOS, MSWindows)
1062 If any of these configuration files exist, each will be expected
1063 to contain a set of default options which are read in the order
1064 listed when ctags starts, but before the CTAGS environment vari‐
1065 able is read or any command line options are read. This makes it
1066 possible to set up site-wide, personal or project-level
1067 defaults. It is possible to compile ctags to read an additional
1068 configuration file before any of those shown above, which will
1069 be indicated if the output produced by the --version option
1070 lists the "custom-conf" feature. Options appearing in the CTAGS
1071 environment variable or on the command line will override
1072 options specified in these files. Only options will be read from
1073 these files. Note that the option files are read in line-ori‐
1074 ented mode in which spaces are significant (since shell quoting
1075 is not possible). Each line of the file is read as one command
1076 line parameter (as if it were quoted with single quotes). There‐
1077 fore, use new lines to indicate separate command-line arguments.
1078
1079
1080 tags The default tag file created by ctags.
1081
1082 TAGS The default tag file created by etags.
1083
1084
1086 The official Exuberant Ctags web site at:
1087
1088 http://ctags.sourceforge.net
1089
1090 Also ex(1), vi(1), elvis, or, better yet, vim, the official editor of
1091 ctags. For more information on vim, see the VIM Pages web site at:
1092
1093 http://www.vim.org/
1094
1095
1096
1098 Darren Hiebert <dhiebert at users.sourceforge.net>
1099 http://DarrenHiebert.com/
1100
1101
1102
1104 "Think ye at all times of rendering some service to every member of the
1105 human race."
1106
1107 "All effort and exertion put forth by man from the fullness of his
1108 heart is worship, if it is prompted by the highest motives and the will
1109 to do service to humanity."
1110
1111 -- From the Baha'i Writings
1112
1113
1114
1116 This version of ctags was originally derived from and inspired by the
1117 ctags program by Steve Kirkendall <kirkenda@cs.pdx.edu> that comes with
1118 the Elvis vi clone (though virtually none of the original code
1119 remains).
1120
1121 Credit is also due Bram Moolenaar <Bram@vim.org>, the author of vim,
1122 who has devoted so much of his time and energy both to developing the
1123 editor as a service to others, and to helping the orphans of Uganda.
1124
1125 The section entitled "HOW TO USE WITH GNU EMACS" was shamelessly stolen
1126 from the info page for GNU etags.
1127
1128
1129
1130Darren Hiebert Version 5.6 CTAGS(1)