Subversion Repositories or1k_old

\input texinfo @c -*-texinfo-*-

@c %**start of header

@setfilename standards.info

@settitle GNU Coding Standards

@c This date is automagically updated when you save this file:

@set lastupdate March 13, 1998

@c %**end of header

@ifinfo

@format

START-INFO-DIR-ENTRY

* Standards: (standards).        GNU coding standards.

END-INFO-DIR-ENTRY

@end format

@end ifinfo

@c @setchapternewpage odd

@setchapternewpage off

@c This is used by a cross ref in make-stds.texi

@set CODESTD  1

@iftex

@set CHAPTER chapter

@end iftex

@ifinfo

@set CHAPTER node

@end ifinfo

@ifinfo

GNU Coding Standards

Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of

this manual provided the copyright notice and this permission notice

are preserved on all copies.

@ignore

Permission is granted to process this file through TeX and print the

results, provided the printed document carries copying permission

notice identical to this one except for the removal of this paragraph

(this paragraph not being relevant to the printed manual).

@end ignore

Permission is granted to copy and distribute modified versions of this

manual under the conditions for verbatim copying, provided that the entire

resulting derived work is distributed under the terms of a permission

notice identical to this one.

Permission is granted to copy and distribute translations of this manual

into another language, under the above conditions for modified versions,

except that this permission notice may be stated in a translation approved

by the Free Software Foundation.

@end ifinfo

@titlepage

@title GNU Coding Standards

@author Richard Stallman

@author last updated @value{lastupdate}

@page

@vskip 0pt plus 1filll

Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of

this manual provided the copyright notice and this permission notice

are preserved on all copies.

Permission is granted to copy and distribute modified versions of this

manual under the conditions for verbatim copying, provided that the entire

resulting derived work is distributed under the terms of a permission

notice identical to this one.

Permission is granted to copy and distribute translations of this manual

into another language, under the above conditions for modified versions,

except that this permission notice may be stated in a translation approved

by the Free Software Foundation.

@end titlepage

@ifinfo

@node Top, Preface, (dir), (dir)

@top Version

Last updated @value{lastupdate}.

@end ifinfo

@menu

* Preface::                     About the GNU Coding Standards

* Intellectual Property::       Keeping Free Software Free

* Design Advice::               General Program Design

* Program Behavior::            Program Behavior for All Programs

* Writing C::                   Making The Best Use of C

* Documentation::               Documenting Programs

* Managing Releases::           The Release Process

@end menu

@node Preface

@chapter About the GNU Coding Standards

The GNU Coding Standards were written by Richard Stallman and other GNU

Project volunteers.  Their purpose is to make the GNU system clean,

consistent, and easy to install.  This document can also be read as a

guide to writing portable, robust and reliable programs.  It focuses on

programs written in C, but many of the rules and principles are useful

even if you write in another programming language.  The rules often

state reasons for writing in a certain way.

Corrections or suggestions for this document should be sent to

@email{gnu@@gnu.org}.  If you make a suggestion, please include a

suggested new wording for it; our time is limited.  We prefer a context

diff to the @file{standards.texi} or @file{make-stds.texi} files, but if

you don't have those files, please mail your suggestion anyway.

This release of the GNU Coding Standards was last updated

@value{lastupdate}.

@node Intellectual Property

@chapter Keeping Free Software Free

This @value{CHAPTER} discusses how you can make sure that GNU software

remains unencumbered.

@menu

* Reading Non-Free Code::       Referring to Proprietary Programs

* Contributions::               Accepting Contributions

@end menu

@node Reading Non-Free Code

@section Referring to Proprietary Programs

Don't in any circumstances refer to Unix source code for or during

your work on GNU!  (Or to any other proprietary programs.)

If you have a vague recollection of the internals of a Unix program,

this does not absolutely mean you can't write an imitation of it, but

do try to organize the imitation internally along different lines,

because this is likely to make the details of the Unix version

irrelevant and dissimilar to your results.

For example, Unix utilities were generally optimized to minimize

memory use; if you go for speed instead, your program will be very

different.  You could keep the entire input file in core and scan it

there instead of using stdio.  Use a smarter algorithm discovered more

recently than the Unix program.  Eliminate use of temporary files.  Do

it in one pass instead of two (we did this in the assembler).

Or, on the contrary, emphasize simplicity instead of speed.  For some

applications, the speed of today's computers makes simpler algorithms

adequate.

Or go for generality.  For example, Unix programs often have static

tables or fixed-size strings, which make for arbitrary limits; use

dynamic allocation instead.  Make sure your program handles NULs and

other funny characters in the input files.  Add a programming language

for extensibility and write part of the program in that language.

Or turn some parts of the program into independently usable libraries.

Or use a simple garbage collector instead of tracking precisely when

to free memory, or use a new GNU facility such as obstacks.

@node Contributions

@section Accepting Contributions

If someone else sends you a piece of code to add to the program you are

working on, we need legal papers to use it---the same sort of legal

papers we will need to get from you.  @emph{Each} significant

contributor to a program must sign some sort of legal papers in order

for us to have clear title to the program.  The main author alone is not

enough.

So, before adding in any contributions from other people, please tell

us, so we can arrange to get the papers.  Then wait until we tell you

that we have received the signed papers, before you actually use the

contribution.

This applies both before you release the program and afterward.  If

you receive diffs to fix a bug, and they make significant changes, we

need legal papers for that change.

This also applies to comments and documentation files.  For copyright

law, comments and code are just text.  Copyright applies to all kinds of

text, so we need legal papers for all kinds.

You don't need papers for changes of a few lines here or there, since

they are not significant for copyright purposes.  Also, you don't need

papers if all you get from the suggestion is some ideas, not actual code

which you use.  For example, if you write a different solution to the

problem, you don't need to get papers.

We know this is frustrating; it's frustrating for us as well.  But if

you don't wait, you are going out on a limb---for example, what if the

contributor's employer won't sign a disclaimer?  You might have to take

that code out again!

The very worst thing is if you forget to tell us about the other

contributor.  We could be very embarrassed in court some day as a

result.

We have more detailed advice for maintainers of programs; if you have

reached the stage of actually maintaining a program for GNU (whether

released or not), please ask us for a copy.

@node Design Advice

@chapter General Program Design

This @value{CHAPTER} discusses some of the issues you should take into

account when designing your program.

@menu

* Compatibility::               Compatibility with other implementations

* Using Extensions::            Using non-standard features

* ANSI C::                      Using ANSI C features

* Source Language::             Using languages other than C

@end menu

@node Compatibility

@section Compatibility with Other Implementations

With occasional exceptions, utility programs and libraries for GNU

should be upward compatible with those in Berkeley Unix, and upward

compatible with @sc{ansi} C if @sc{ansi} C specifies their behavior, and

upward compatible with @sc{POSIX} if @sc{POSIX} specifies their

behavior.

When these standards conflict, it is useful to offer compatibility

modes for each of them.

@sc{ansi} C and @sc{POSIX} prohibit many kinds of extensions.  Feel free

to make the extensions anyway, and include a @samp{--ansi},

@samp{--posix}, or @samp{--compatible} option to turn them off.

However, if the extension has a significant chance of breaking any real

programs or scripts, then it is not really upward compatible.  Try to

redesign its interface.

Many GNU programs suppress extensions that conflict with POSIX if the

environment variable @code{POSIXLY_CORRECT} is defined (even if it is

defined with a null value).  Please make your program recognize this

variable if appropriate.

When a feature is used only by users (not by programs or command

files), and it is done poorly in Unix, feel free to replace it

completely with something totally different and better.  (For example,

@code{vi} is replaced with Emacs.)  But it is nice to offer a compatible

feature as well.  (There is a free @code{vi} clone, so we offer it.)

Additional useful features not in Berkeley Unix are welcome.

@node Using Extensions

@section Using Non-standard Features

Many GNU facilities that already exist support a number of convenient

extensions over the comparable Unix facilities.  Whether to use these

extensions in implementing your program is a difficult question.

On the one hand, using the extensions can make a cleaner program.

On the other hand, people will not be able to build the program

unless the other GNU tools are available.  This might cause the

program to work on fewer kinds of machines.

With some extensions, it might be easy to provide both alternatives.

For example, you can define functions with a ``keyword'' @code{INLINE}

and define that as a macro to expand into either @code{inline} or

nothing, depending on the compiler.

In general, perhaps it is best not to use the extensions if you can

straightforwardly do without them, but to use the extensions if they

are a big improvement.

An exception to this rule are the large, established programs (such as

Emacs) which run on a great variety of systems.  Such programs would

be broken by use of GNU extensions.

Another exception is for programs that are used as part of

compilation: anything that must be compiled with other compilers in

order to bootstrap the GNU compilation facilities.  If these require

the GNU compiler, then no one can compile them without having them

installed already.  That would be no good.

@node ANSI C

@section @sc{ansi} C and pre-@sc{ansi} C

Do not ever use the ``trigraph'' feature of @sc{ansi} C.

@sc{ansi} C is widespread enough now that it is ok to write new programs

that use @sc{ansi} C features (and therefore will not work in

non-@sc{ansi} compilers).  And if a program is already written in

@sc{ansi} C, there's no need to convert it to support non-@sc{ansi}

compilers.

However, it is easy to support non-@sc{ansi} compilers in most programs,

so you might still consider doing so when you write a program.  Instead

of writing function definitions in @sc{ansi} prototype form,

@example

int

foo (int x, int y)

@dots{}

@end example

@noindent

write the definition in pre-@sc{ansi} style like this,

@example

int

foo (x, y)

     int x, y;

@dots{}

@end example

@noindent

and use a separate declaration to specify the argument prototype:

@example

int foo (int, int);

@end example

You need such a declaration anyway, in a header file, to get the benefit

of @sc{ansi} C prototypes in all the files where the function is called.

And once you have it, you lose nothing by writing the function

definition in the pre-@sc{ansi} style.

If you don't know non-@sc{ansi} C, there's no need to learn it; just

write in @sc{ansi} C.

@node Source Language

@section Using Languages Other Than C

Using a language other than C is like using a non-standard feature: it

will cause trouble for users.  Even if GCC supports the other language,

users may find it inconvenient to have to install the compiler for that

other language in order to build your program.  For example, if you

write your program in C++, people will have to install the C++ compiler

in order to compile your program.  Thus, it is better if you write in C.

But there are three situations when there is no disadvantage in using

some other language:

@itemize @bullet

@item

It is okay to use another language if your program contains an

interpreter for that language.

For example, if your program links with GUILE, it is ok to write part of

the program in Scheme or another language supported by GUILE.

@item

It is okay to use another language in a tool specifically intended for

use with that language.

This is okay because the only people who want to build the tool will be

those who have installed the other language anyway.

@item

If an application is of interest to a narrow community, then perhaps

it's not important if the application is inconvenient to install.

@end itemize

C has one other advantage over C++ and other compiled languages: more

people know C, so more people will find it easy to read and modify the

program if it is written in C.

@node Program Behavior

@chapter Program Behavior for All Programs

This @value{CHAPTER} describes how to write robust software. It also

describes general standards for error messages, the command line interface,

and how libraries should behave.

@menu

* Semantics::                   Writing robust programs

* Libraries::                   Library behavior

* Errors::                      Formatting error messages

* User Interfaces::             Standards for command line interfaces

* Option Table::                Table of long options.

* Memory Usage::                When and how to care about memory needs

@end menu

@node Semantics

@section Writing Robust Programs

Avoid arbitrary limits on the length or number of @emph{any} data

structure, including file names, lines, files, and symbols, by allocating

all data structures dynamically.  In most Unix utilities, ``long lines

are silently truncated''.  This is not acceptable in a GNU utility.

Utilities reading files should not drop NUL characters, or any other

nonprinting characters @emph{including those with codes above 0177}.  The

only sensible exceptions would be utilities specifically intended for

interface to certain types of printers that can't handle those characters.

Check every system call for an error return, unless you know you wish to

ignore errors.  Include the system error text (from @code{perror} or

equivalent) in @emph{every} error message resulting from a failing

system call, as well as the name of the file if any and the name of the

utility.  Just ``cannot open foo.c'' or ``stat failed'' is not

sufficient.

Check every call to @code{malloc} or @code{realloc} to see if it

returned zero.  Check @code{realloc} even if you are making the block

smaller; in a system that rounds block sizes to a power of 2,

@code{realloc} may get a different block if you ask for less space.

In Unix, @code{realloc} can destroy the storage block if it returns

zero.  GNU @code{realloc} does not have this bug: if it fails, the

original block is unchanged.  Feel free to assume the bug is fixed.  If

you wish to run your program on Unix, and wish to avoid lossage in this

case, you can use the GNU @code{malloc}.

You must expect @code{free} to alter the contents of the block that was

freed.  Anything you want to fetch from the block, you must fetch before

calling @code{free}.

If @code{malloc} fails in a noninteractive program, make that a fatal

error.  In an interactive program (one that reads commands from the

user), it is better to abort the command and return to the command

reader loop.  This allows the user to kill other processes to free up

virtual memory, and then try the command again.

Use @code{getopt_long} to decode arguments, unless the argument syntax

makes this unreasonable.

When static storage is to be written in during program execution, use

explicit C code to initialize it.  Reserve C initialized declarations

for data that will not be changed.

@c ADR: why?

Try to avoid low-level interfaces to obscure Unix data structures (such

as file directories, utmp, or the layout of kernel memory), since these

are less likely to work compatibly.  If you need to find all the files

in a directory, use @code{readdir} or some other high-level interface.

These will be supported compatibly by GNU.

By default, the GNU system will provide the signal handling functions of

@sc{BSD} and of @sc{POSIX}.  So GNU software should be written to use

these.

In error checks that detect ``impossible'' conditions, just abort.

There is usually no point in printing any message.  These checks

indicate the existence of bugs.  Whoever wants to fix the bugs will have

to read the source code and run a debugger.  So explain the problem with

comments in the source.  The relevant data will be in variables, which

are easy to examine with the debugger, so there is no point moving them

elsewhere.

Do not use a count of errors as the exit status for a program.

@emph{That does not work}, because exit status values are limited to 8

bits (0 through 255).  A single run of the program might have 256

errors; if you try to return 256 as the exit status, the parent process

will see 0 as the status, and it will appear that the program succeeded.

If you make temporary files, check the @code{TMPDIR} environment

variable; if that variable is defined, use the specified directory

instead of @file{/tmp}.

@node Libraries

@section Library Behavior

Try to make library functions reentrant.  If they need to do dynamic

storage allocation, at least try to avoid any nonreentrancy aside from

that of @code{malloc} itself.

Here are certain name conventions for libraries, to avoid name

conflicts.

Choose a name prefix for the library, more than two characters long.

All external function and variable names should start with this

prefix.  In addition, there should only be one of these in any given

library member.  This usually means putting each one in a separate

source file.

An exception can be made when two external symbols are always used

together, so that no reasonable program could use one without the

other; then they can both go in the same file.

External symbols that are not documented entry points for the user

should have names beginning with @samp{_}.  They should also contain

the chosen name prefix for the library, to prevent collisions with

other libraries.  These can go in the same files with user entry

points if you like.

Static functions and variables can be used as you like and need not

fit any naming convention.

@node Errors

@section Formatting Error Messages

Error messages from compilers should look like this:

@example

@var{source-file-name}:@var{lineno}: @var{message}

@end example

Error messages from other noninteractive programs should look like this:

@example

@var{program}:@var{source-file-name}:@var{lineno}: @var{message}

@end example

@noindent

when there is an appropriate source file, or like this:

@example

@var{program}: @var{message}

@end example

@noindent

when there is no relevant source file.

In an interactive program (one that is reading commands from a

terminal), it is better not to include the program name in an error

message.  The place to indicate which program is running is in the

prompt or with the screen layout.  (When the same program runs with

input from a source other than a terminal, it is not interactive and

would do best to print error messages using the noninteractive style.)

The string @var{message} should not begin with a capital letter when

it follows a program name and/or file name.  Also, it should not end

with a period.

Error messages from interactive programs, and other messages such as

usage messages, should start with a capital letter.  But they should not

end with a period.

@node User Interfaces

@section Standards for Command Line Interfaces

Please don't make the behavior of a utility depend on the name used

to invoke it.  It is useful sometimes to make a link to a utility

with a different name, and that should not change what it does.

Instead, use a run time option or a compilation switch or both

to select among the alternate behaviors.

Likewise, please don't make the behavior of the program depend on the

type of output device it is used with.  Device independence is an

important principle of the system's design; do not compromise it

merely to save someone from typing an option now and then.

If you think one behavior is most useful when the output is to a

terminal, and another is most useful when the output is a file or a

pipe, then it is usually best to make the default behavior the one that

is useful with output to a terminal, and have an option for the other

behavior.

Compatibility requires certain programs to depend on the type of output

device.  It would be disastrous if @code{ls} or @code{sh} did not do so

in the way all users expect.  In some of these cases, we supplement the

program with a preferred alternate version that does not depend on the

output device type.  For example, we provide a @code{dir} program much

like @code{ls} except that its default output format is always

multi-column format.

It is a good idea to follow the @sc{POSIX} guidelines for the

command-line options of a program.  The easiest way to do this is to use

@code{getopt} to parse them.  Note that the GNU version of @code{getopt}

will normally permit options anywhere among the arguments unless the

special argument @samp{--} is used.  This is not what @sc{POSIX}

specifies; it is a GNU extension.

Please define long-named options that are equivalent to the

single-letter Unix-style options.  We hope to make GNU more user

friendly this way.  This is easy to do with the GNU function

@code{getopt_long}.

One of the advantages of long-named options is that they can be

consistent from program to program.  For example, users should be able

to expect the ``verbose'' option of any GNU program which has one, to be

spelled precisely @samp{--verbose}.  To achieve this uniformity, look at

the table of common long-option names when you choose the option names

for your program (@pxref{Option Table}).

It is usually a good idea for file names given as ordinary arguments to

be input files only; any output files would be specified using options

(preferably @samp{-o} or @samp{--output}).  Even if you allow an output

file name as an ordinary argument for compatibility, try to provide an

option as another way to specify it.  This will lead to more consistency

among GNU utilities, and fewer idiosyncracies for users to remember.

All programs should support two standard options: @samp{--version}

and @samp{--help}.

@table @code

@item --version

This option should direct the program to information about its name,

version, origin and legal status, all on standard output, and then exit

successfully.  Other options and arguments should be ignored once this

is seen, and the program should not perform its normal function.

The first line is meant to be easy for a program to parse; the version

number proper starts after the last space.  In addition, it contains

the canonical name for this program, in this format:

@example

GNU Emacs 19.30

@end example

@noindent

The program's name should be a constant string; @emph{don't} compute it

from @code{argv[0]}.  The idea is to state the standard or canonical

name for the program, not its file name.  There are other ways to find

out the precise file name where a command is found in @code{PATH}.

If the program is a subsidiary part of a larger package, mention the

package name in parentheses, like this:

@example

emacsserver (GNU Emacs) 19.30

@end example

@noindent

If the package has a version number which is different from this

program's version number, you can mention the package version number

just before the close-parenthesis.

If you @strong{need} to mention the version numbers of libraries which

are distributed separately from the package which contains this program,

you can do so by printing an additional line of version info for each

library you want to mention.  Use the same format for these lines as for

the first line.

Please do not mention all of the libraries that the program uses ``just

for completeness''---that would produce a lot of unhelpful clutter.

Please mention library version numbers only if you find in practice that

they are very important to you in debugging.

The following line, after the version number line or lines, should be a

copyright notice.  If more than one copyright notice is called for, put

each on a separate line.

Next should follow a brief statement that the program is free software,

and that users are free to copy and change it on certain conditions.  If

the program is covered by the GNU GPL, say so here.  Also mention that

there is no warranty, to the extent permitted by law.

It is ok to finish the output with a list of the major authors of the

program, as a way of giving credit.

Here's an example of output that follows these rules:

@smallexample

GNU Emacs 19.34.5

Copyright (C) 1996 Free Software Foundation, Inc.

GNU Emacs comes with NO WARRANTY,

to the extent permitted by law.

You may redistribute copies of GNU Emacs

under the terms of the GNU General Public License.

For more information about these matters,

see the files named COPYING.

@end smallexample

You should adapt this to your program, of course, filling in the proper

year, copyright holder, name of program, and the references to

distribution terms, and changing the rest of the wording as necessary.

This copyright notice only needs to mention the most recent year in

which changes were made---there's no need to list the years for previous

versions' changes.  You don't have to mention the name of the program in

these notices, if that is inconvenient, since it appeared in the first

line.

@item --help

This option should output brief documentation for how to invoke the

program, on standard output, then exit successfully.  Other options and

arguments should be ignored once this is seen, and the program should

not perform its normal function.

Near the end of the @samp{--help} option's output there should be a line

that says where to mail bug reports.  It should have this format:

@example

Report bugs to @var{mailing-address}.

@end example

@end table

@node Option Table

@section Table of Long Options

Here is a table of long options used by GNU programs.  It is surely

incomplete, but we aim to list all the options that a new program might

want to be compatible with.  If you use names not already in the table,

please send @email{gnu@@gnu.org} a list of them, with their

meanings, so we can update the table.

@c Please leave newlines between items in this table; it's much easier

@c to update when it isn't completely squashed together and unreadable.

@c When there is more than one short option for a long option name, put

@c a semicolon between the lists of the programs that use them, not a

@c period.   --friedman

@table @samp

@item after-date

@samp{-N} in @code{tar}.

@item all

@samp{-a} in @code{du}, @code{ls}, @code{nm}, @code{stty}, @code{uname},

and @code{unexpand}.

@item all-text

@samp{-a} in @code{diff}.

@item almost-all

@samp{-A} in @code{ls}.

@item append

@samp{-a} in @code{etags}, @code{tee}, @code{time};

@samp{-r} in @code{tar}.

@item archive

@samp{-a} in @code{cp}.

@item archive-name

@samp{-n} in @code{shar}.

@item arglength

@samp{-l} in @code{m4}.

@item ascii

@samp{-a} in @code{diff}.

@item assign

@samp{-v} in @code{gawk}.

@item assume-new

@samp{-W} in Make.

@item assume-old

@samp{-o} in Make.

@item auto-check

@samp{-a} in @code{recode}.

@item auto-pager

@samp{-a} in @code{wdiff}.

@item auto-reference

@samp{-A} in @code{ptx}.

@item avoid-wraps

@samp{-n} in @code{wdiff}.

@item backward-search

@samp{-B} in @code{ctags}.

@item basename

@samp{-f} in @code{shar}.

@item batch

Used in GDB.

@item baud

Used in GDB.

@item before

@samp{-b} in @code{tac}.

@item binary

@samp{-b} in @code{cpio} and @code{diff}.

@item bits-per-code

@samp{-b} in @code{shar}.

@item block-size

Used in @code{cpio} and @code{tar}.

@item blocks

@samp{-b} in @code{head} and @code{tail}.

@item break-file

@samp{-b} in @code{ptx}.

@item brief

Used in various programs to make output shorter.

@item bytes

@samp{-c} in @code{head}, @code{split}, and @code{tail}.

@item c@t{++}

@samp{-C} in @code{etags}.

@item catenate

@samp{-A} in @code{tar}.

@item cd

Used in various programs to specify the directory to use.

@item changes

@samp{-c} in @code{chgrp} and @code{chown}.

@item classify

@samp{-F} in @code{ls}.

@item colons

@samp{-c} in @code{recode}.

@item command

@samp{-c} in @code{su};

@samp{-x} in GDB.

@item compare

@samp{-d} in @code{tar}.

@item compat

Used in @code{gawk}.

@item compress

@samp{-Z} in @code{tar} and @code{shar}.

@item concatenate

@samp{-A} in @code{tar}.

@item confirmation

@samp{-w} in @code{tar}.

@item context

Used in @code{diff}.

@item copyleft

@samp{-W copyleft} in @code{gawk}.

@item copyright

@samp{-C} in @code{ptx}, @code{recode}, and @code{wdiff};

@samp{-W copyright} in @code{gawk}.

@item core

Used in GDB.

@item count

@samp{-q} in @code{who}.

@item count-links

@samp{-l} in @code{du}.

@item create

Used in @code{tar} and @code{cpio}.

@item cut-mark

@samp{-c} in @code{shar}.

@item cxref

@samp{-x} in @code{ctags}.

@item date

@samp{-d} in @code{touch}.

@item debug

@samp{-d} in Make and @code{m4};

@samp{-t} in Bison.

@item define

@samp{-D} in @code{m4}.

@item defines

@samp{-d} in Bison and @code{ctags}.

@item delete

@samp{-D} in @code{tar}.

@item dereference

@samp{-L} in @code{chgrp}, @code{chown}, @code{cpio}, @code{du},

@code{ls}, and @code{tar}.

@item dereference-args

@samp{-D} in @code{du}.

@item diacritics

@samp{-d} in @code{recode}.

@item dictionary-order

@samp{-d} in @code{look}.

@item diff

@samp{-d} in @code{tar}.

@item digits

@samp{-n} in @code{csplit}.

@item directory

Specify the directory to use, in various programs.  In @code{ls}, it

means to show directories themselves rather than their contents.  In

@code{rm} and @code{ln}, it means to not treat links to directories

specially.

@item discard-all

@samp{-x} in @code{strip}.

@item discard-locals

@samp{-X} in @code{strip}.

@item dry-run

@samp{-n} in Make.

@item ed

@samp{-e} in @code{diff}.

@item elide-empty-files

@samp{-z} in @code{csplit}.

@item end-delete

@samp{-x} in @code{wdiff}.

@item end-insert

@samp{-z} in @code{wdiff}.

@item entire-new-file

@samp{-N} in @code{diff}.

@item environment-overrides

@samp{-e} in Make.

@item eof

@samp{-e} in @code{xargs}.

@item epoch

Used in GDB.

@item error-limit

Used in @code{makeinfo}.

@item error-output

@samp{-o} in @code{m4}.

@item escape

@samp{-b} in @code{ls}.

@item exclude-from

@samp{-X} in @code{tar}.

@item exec

Used in GDB.

@item exit

@samp{-x} in @code{xargs}.

@item exit-0

@samp{-e} in @code{unshar}.

@item expand-tabs

@samp{-t} in @code{diff}.