Subversion Repositories or1k

START-INFO-DIR-ENTRY

START-INFO-DIR-ENTRY

* Standards: (standards).        GNU coding standards.

* Standards: (standards).        GNU coding standards.

END-INFO-DIR-ENTRY

END-INFO-DIR-ENTRY

   GNU Coding Standards Copyright (C) 1992, 1993, 1994, 1995, 1996,

   GNU Coding Standards Copyright (C) 1992, 1993, 1994, 1995, 1996,

1997, 1998 Free Software Foundation, Inc.

1997, 1998 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this

   Permission is granted to make and distribute verbatim copies of this

manual provided the copyright notice and this permission notice are

manual provided the copyright notice and this permission notice are

preserved on all copies.

preserved on all copies.

   Permission is granted to copy and distribute modified versions of

   Permission is granted to copy and distribute modified versions of

this manual under the conditions for verbatim copying, provided that

this manual under the conditions for verbatim copying, provided that

the entire resulting derived work is distributed under the terms of a

the entire resulting derived work is distributed under the terms of a

permission notice identical to this one.

permission notice identical to this one.

   Permission is granted to copy and distribute translations of this

   Permission is granted to copy and distribute translations of this

manual into another language, under the above conditions for modified

manual into another language, under the above conditions for modified

versions, except that this permission notice may be stated in a

versions, except that this permission notice may be stated in a

translation approved by the Free Software Foundation.

translation approved by the Free Software Foundation.

File: standards.info,  Node: Top,  Next: Preface,  Prev: (dir),  Up: (dir)

File: standards.info,  Node: Top,  Next: Preface,  Prev: (dir),  Up: (dir)

Version

Version

*******

*******

   Last updated March 13, 1998.

   Last updated March 13, 1998.

* Menu:

* Menu:

* Preface::                     About the GNU Coding Standards

* Preface::                     About the GNU Coding Standards

* Intellectual Property::       Keeping Free Software Free

* Intellectual Property::       Keeping Free Software Free

* Design Advice::               General Program Design

* Design Advice::               General Program Design

* Program Behavior::            Program Behavior for All Programs

* Program Behavior::            Program Behavior for All Programs

* Writing C::                   Making The Best Use of C

* Writing C::                   Making The Best Use of C

* Documentation::               Documenting Programs

* Documentation::               Documenting Programs

* Managing Releases::           The Release Process

* Managing Releases::           The Release Process

File: standards.info,  Node: Preface,  Next: Intellectual Property,  Prev: Top,  Up: Top

File: standards.info,  Node: Preface,  Next: Intellectual Property,  Prev: Top,  Up: Top

About the GNU Coding Standards

About the GNU Coding Standards

******************************

******************************

   The GNU Coding Standards were written by Richard Stallman and other

   The GNU Coding Standards were written by Richard Stallman and other

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

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

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

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

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

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

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

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

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

state reasons for writing in a certain way.

state reasons for writing in a certain way.

   Corrections or suggestions for this document should be sent to

   Corrections or suggestions for this document should be sent to

.  If you make a suggestion, please include a suggested

.  If you make a suggestion, please include a suggested

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

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

the `standards.texi' or `make-stds.texi' files, but if you don't have

the `standards.texi' or `make-stds.texi' files, but if you don't have

those files, please mail your suggestion anyway.

those files, please mail your suggestion anyway.

   This release of the GNU Coding Standards was last updated March 13,

   This release of the GNU Coding Standards was last updated March 13,

1998.

1998.

File: standards.info,  Node: Intellectual Property,  Next: Design Advice,  Prev: Preface,  Up: Top

File: standards.info,  Node: Intellectual Property,  Next: Design Advice,  Prev: Preface,  Up: Top

Keeping Free Software Free

Keeping Free Software Free

**************************

**************************

   This node discusses how you can make sure that GNU software remains

   This node discusses how you can make sure that GNU software remains

unencumbered.

unencumbered.

* Menu:

* Menu:

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

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

* Contributions::               Accepting Contributions

* Contributions::               Accepting Contributions

File: standards.info,  Node: Reading Non-Free Code,  Next: Contributions,  Up: Intellectual Property

File: standards.info,  Node: Reading Non-Free Code,  Next: Contributions,  Up: Intellectual Property

Referring to Proprietary Programs

Referring to Proprietary Programs

=================================

=================================

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

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

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

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

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

   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

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

do try to organize the imitation internally along different lines,

do try to organize the imitation internally along different lines,

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

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

irrelevant and dissimilar to your results.

irrelevant and dissimilar to your results.

   For example, Unix utilities were generally optimized to minimize

   For example, Unix utilities were generally optimized to minimize

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

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

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

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

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

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

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

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

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

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

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

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

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

adequate.

adequate.

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

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

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

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

dynamic allocation instead.  Make sure your program handles NULs and

dynamic allocation instead.  Make sure your program handles NULs and

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

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

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

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

   Or turn some parts of the program into independently usable

   Or turn some parts of the program into independently usable

libraries.  Or use a simple garbage collector instead of tracking

libraries.  Or use a simple garbage collector instead of tracking

precisely when to free memory, or use a new GNU facility such as

precisely when to free memory, or use a new GNU facility such as

obstacks.

obstacks.

File: standards.info,  Node: Contributions,  Prev: Reading Non-Free Code,  Up: Intellectual Property

File: standards.info,  Node: Contributions,  Prev: Reading Non-Free Code,  Up: Intellectual Property

Accepting Contributions

Accepting Contributions

=======================

=======================

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

   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

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

a program must sign some sort of legal papers in order for us to have

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.

clear title to the program.  The main author alone is not enough.

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

   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

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

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

contribution.

contribution.

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

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

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

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

need legal papers for that change.

need legal papers for that change.

   This also applies to comments and documentation files.  For copyright

   This also applies to comments and documentation files.  For copyright

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

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

text, so we need legal papers for all kinds.

text, so we need legal papers for all kinds.

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

   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

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

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

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

problem, you don't need to get papers.

problem, you don't need to get papers.

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

   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

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

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

that code out again!

that code out again!

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

   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

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

result.

result.

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

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

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

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

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

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

File: standards.info,  Node: Design Advice,  Next: Program Behavior,  Prev: Intellectual Property,  Up: Top

File: standards.info,  Node: Design Advice,  Next: Program Behavior,  Prev: Intellectual Property,  Up: Top

General Program Design

General Program Design

**********************

**********************

   This node discusses some of the issues you should take into account

   This node discusses some of the issues you should take into account

when designing your program.

when designing your program.

* Menu:

* Menu:

* Compatibility::               Compatibility with other implementations

* Compatibility::               Compatibility with other implementations

* Using Extensions::            Using non-standard features

* Using Extensions::            Using non-standard features

* ANSI C::                      Using ANSI C features

* ANSI C::                      Using ANSI C features

* Source Language::             Using languages other than C

* Source Language::             Using languages other than C

File: standards.info,  Node: Compatibility,  Next: Using Extensions,  Up: Design Advice

File: standards.info,  Node: Compatibility,  Next: Using Extensions,  Up: Design Advice

Compatibility with Other Implementations

Compatibility with Other Implementations

========================================

========================================

   With occasional exceptions, utility programs and libraries for GNU

   With occasional exceptions, utility programs and libraries for GNU

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

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

compatible with ANSI C if ANSI C specifies their behavior, and upward

compatible with ANSI C if ANSI C specifies their behavior, and upward

compatible with POSIX if POSIX specifies their behavior.

compatible with POSIX if POSIX specifies their behavior.

   When these standards conflict, it is useful to offer compatibility

   When these standards conflict, it is useful to offer compatibility

modes for each of them.

modes for each of them.

   ANSI C and POSIX prohibit many kinds of extensions.  Feel free to

   ANSI C and POSIX prohibit many kinds of extensions.  Feel free to

make the extensions anyway, and include a `--ansi', `--posix', or

make the extensions anyway, and include a `--ansi', `--posix', or

`--compatible' option to turn them off.  However, if the extension has

`--compatible' option to turn them off.  However, if the extension has

a significant chance of breaking any real programs or scripts, then it

a significant chance of breaking any real programs or scripts, then it

is not really upward compatible.  Try to redesign its interface.

is not really upward compatible.  Try to redesign its interface.

   Many GNU programs suppress extensions that conflict with POSIX if the

   Many GNU programs suppress extensions that conflict with POSIX if the

environment variable `POSIXLY_CORRECT' is defined (even if it is

environment variable `POSIXLY_CORRECT' is defined (even if it is

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

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

variable if appropriate.

variable if appropriate.

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

   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

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

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

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

`vi' is replaced with Emacs.)  But it is nice to offer a compatible

`vi' is replaced with Emacs.)  But it is nice to offer a compatible

feature as well.  (There is a free `vi' clone, so we offer it.)

feature as well.  (There is a free `vi' clone, so we offer it.)

   Additional useful features not in Berkeley Unix are welcome.

   Additional useful features not in Berkeley Unix are welcome.

File: standards.info,  Node: Using Extensions,  Next: ANSI C,  Prev: Compatibility,  Up: Design Advice

File: standards.info,  Node: Using Extensions,  Next: ANSI C,  Prev: Compatibility,  Up: Design Advice

Using Non-standard Features

Using Non-standard Features

===========================

===========================

   Many GNU facilities that already exist support a number of convenient

   Many GNU facilities that already exist support a number of convenient

extensions over the comparable Unix facilities.  Whether to use these

extensions over the comparable Unix facilities.  Whether to use these

extensions in implementing your program is a difficult question.

extensions in implementing your program is a difficult question.

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

   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

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

the other GNU tools are available.  This might cause the program to

work on fewer kinds of machines.

work on fewer kinds of machines.

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

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

For example, you can define functions with a "keyword" `INLINE' and

For example, you can define functions with a "keyword" `INLINE' and

define that as a macro to expand into either `inline' or nothing,

define that as a macro to expand into either `inline' or nothing,

depending on the compiler.

depending on the compiler.

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

   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

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

are a big improvement.

are a big improvement.

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

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

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

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

be broken by use of GNU extensions.

be broken by use of GNU extensions.

   Another exception is for programs that are used as part of

   Another exception is for programs that are used as part of

compilation: anything that must be compiled with other compilers in

compilation: anything that must be compiled with other compilers in

order to bootstrap the GNU compilation facilities.  If these require

order to bootstrap the GNU compilation facilities.  If these require

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

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

installed already.  That would be no good.

installed already.  That would be no good.

File: standards.info,  Node: ANSI C,  Next: Source Language,  Prev: Using Extensions,  Up: Design Advice

File: standards.info,  Node: ANSI C,  Next: Source Language,  Prev: Using Extensions,  Up: Design Advice

ANSI C and pre-ANSI C

ANSI C and pre-ANSI C

=====================

=====================

   Do not ever use the "trigraph" feature of ANSI C.

   Do not ever use the "trigraph" feature of ANSI C.

   ANSI C is widespread enough now that it is ok to write new programs

   ANSI C is widespread enough now that it is ok to write new programs

that use ANSI C features (and therefore will not work in non-ANSI

that use ANSI C features (and therefore will not work in non-ANSI

compilers).  And if a program is already written in ANSI C, there's no

compilers).  And if a program is already written in ANSI C, there's no

need to convert it to support non-ANSI compilers.

need to convert it to support non-ANSI compilers.

   However, it is easy to support non-ANSI compilers in most programs,

   However, it is easy to support non-ANSI compilers in most programs,

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

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

of writing function definitions in ANSI prototype form,

of writing function definitions in ANSI prototype form,

     int

     int

     foo (int x, int y)

     foo (int x, int y)

     ...

     ...

write the definition in pre-ANSI style like this,

write the definition in pre-ANSI style like this,

     int

     int

     foo (x, y)

     foo (x, y)

          int x, y;

          int x, y;

     ...

     ...

and use a separate declaration to specify the argument prototype:

and use a separate declaration to specify the argument prototype:

     int foo (int, int);

     int foo (int, int);

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

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

benefit of ANSI C prototypes in all the files where the function is

benefit of ANSI C prototypes in all the files where the function is

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

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

definition in the pre-ANSI style.

definition in the pre-ANSI style.

   If you don't know non-ANSI C, there's no need to learn it; just

   If you don't know non-ANSI C, there's no need to learn it; just

write in ANSI C.

write in ANSI C.

File: standards.info,  Node: Source Language,  Prev: ANSI C,  Up: Design Advice

File: standards.info,  Node: Source Language,  Prev: ANSI C,  Up: Design Advice

Using Languages Other Than C

Using Languages Other Than C

============================

============================

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

   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

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

language, users may find it inconvenient to have to install the

language, users may find it inconvenient to have to install the

compiler for that other language in order to build your program.  For

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

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

the C++ compiler in order to compile your program.  Thus, it is better

if you write in C.

if you write in C.

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

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

some other language:

some other language:

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

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

     interpreter for that language.

     interpreter for that language.

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

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

     part of the program in Scheme or another language supported by

     part of the program in Scheme or another language supported by

     GUILE.

     GUILE.

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

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

     for use with that language.

     for use with that language.

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

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

     will be those who have installed the other language anyway.

     will be those who have installed the other language anyway.

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

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

     perhaps it's not important if the application is inconvenient to

     perhaps it's not important if the application is inconvenient to

     install.

     install.

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

   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

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

program if it is written in C.

program if it is written in C.

File: standards.info,  Node: Program Behavior,  Next: Writing C,  Prev: Design Advice,  Up: Top

File: standards.info,  Node: Program Behavior,  Next: Writing C,  Prev: Design Advice,  Up: Top

Program Behavior for All Programs

Program Behavior for All Programs

*********************************

*********************************

   This node describes how to write robust software. It also describes

   This node describes how to write robust software. It also describes

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

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

how libraries should behave.

how libraries should behave.

* Menu:

* Menu:

* Semantics::                   Writing robust programs

* Semantics::                   Writing robust programs

* Libraries::                   Library behavior

* Libraries::                   Library behavior

* Errors::                      Formatting error messages

* Errors::                      Formatting error messages

* User Interfaces::             Standards for command line interfaces

* User Interfaces::             Standards for command line interfaces

* Option Table::                Table of long options.

* Option Table::                Table of long options.

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

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

File: standards.info,  Node: Semantics,  Next: Libraries,  Up: Program Behavior

File: standards.info,  Node: Semantics,  Next: Libraries,  Up: Program Behavior

Writing Robust Programs

Writing Robust Programs

=======================

=======================

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

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

allocating all data structures dynamically.  In most Unix utilities,

allocating all data structures dynamically.  In most Unix utilities,

"long lines are silently truncated".  This is not acceptable in a GNU

"long lines are silently truncated".  This is not acceptable in a GNU

utility.

utility.

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

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

only sensible exceptions would be utilities specifically intended for

only sensible exceptions would be utilities specifically intended for

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

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

characters.

characters.

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

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

wish to ignore errors.  Include the system error text (from `perror' or

wish to ignore errors.  Include the system error text (from `perror' or

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

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.

utility.  Just "cannot open foo.c" or "stat failed" is not sufficient.

   Check every call to `malloc' or `realloc' to see if it returned

   Check every call to `malloc' or `realloc' to see if it returned

zero.  Check `realloc' even if you are making the block smaller; in a

zero.  Check `realloc' even if you are making the block smaller; in a

system that rounds block sizes to a power of 2, `realloc' may get a

system that rounds block sizes to a power of 2, `realloc' may get a

different block if you ask for less space.

different block if you ask for less space.

   In Unix, `realloc' can destroy the storage block if it returns zero.

   In Unix, `realloc' can destroy the storage block if it returns zero.

GNU `realloc' does not have this bug: if it fails, the original block

GNU `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

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

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

can use the GNU `malloc'.

can use the GNU `malloc'.

   You must expect `free' to alter the contents of the block that was

   You must expect `free' to alter the contents of the block that was

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

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

calling `free'.

calling `free'.

   If `malloc' fails in a noninteractive program, make that a fatal

   If `malloc' fails in a noninteractive program, make that a fatal

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

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

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

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

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

virtual memory, and then try the command again.

virtual memory, and then try the command again.

   Use `getopt_long' to decode arguments, unless the argument syntax

   Use `getopt_long' to decode arguments, unless the argument syntax

makes this unreasonable.

makes this unreasonable.

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

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

explicit C code to initialize it.  Reserve C initialized declarations

explicit C code to initialize it.  Reserve C initialized declarations

for data that will not be changed.

for data that will not be changed.

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

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

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

(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

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

files in a directory, use `readdir' or some other high-level interface.

files in a directory, use `readdir' or some other high-level interface.

These will be supported compatibly by GNU.

These will be supported compatibly by GNU.

   By default, the GNU system will provide the signal handling

   By default, the GNU system will provide the signal handling

functions of BSD and of POSIX.  So GNU software should be written to use

functions of BSD and of POSIX.  So GNU software should be written to use

these.

these.

   In error checks that detect "impossible" conditions, just abort.

   In error checks that detect "impossible" conditions, just abort.

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

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

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

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

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

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

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

elsewhere.

elsewhere.

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

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

(0 through 255).  A single run of the program might have 256 errors; if

(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

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.

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

   If you make temporary files, check the `TMPDIR' environment

   If you make temporary files, check the `TMPDIR' environment

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

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

instead of `/tmp'.

instead of `/tmp'.

File: standards.info,  Node: Libraries,  Next: Errors,  Prev: Semantics,  Up: Program Behavior

File: standards.info,  Node: Libraries,  Next: Errors,  Prev: Semantics,  Up: Program Behavior

Library Behavior

Library Behavior

================

================

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

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

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

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

that of `malloc' itself.

that of `malloc' itself.

   Here are certain name conventions for libraries, to avoid name

   Here are certain name conventions for libraries, to avoid name

conflicts.

conflicts.

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

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

All external function and variable names should start with this prefix.

All external function and variable names should start with this prefix.

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

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.

member.  This usually means putting each one in a separate source file.

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

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

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

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

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

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

   External symbols that are not documented entry points for the user

   External symbols that are not documented entry points for the user

should have names beginning with `_'.  They should also contain the

should have names beginning with `_'.  They should also contain the

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

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

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

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

you like.

you like.

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

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

fit any naming convention.

fit any naming convention.

File: standards.info,  Node: Errors,  Next: User Interfaces,  Prev: Libraries,  Up: Program Behavior

File: standards.info,  Node: Errors,  Next: User Interfaces,  Prev: Libraries,  Up: Program Behavior

Formatting Error Messages

Formatting Error Messages

=========================

=========================

   Error messages from compilers should look like this:

   Error messages from compilers should look like this:

     SOURCE-FILE-NAME:LINENO: MESSAGE

     SOURCE-FILE-NAME:LINENO: MESSAGE

   Error messages from other noninteractive programs should look like

   Error messages from other noninteractive programs should look like

this:

this:

     PROGRAM:SOURCE-FILE-NAME:LINENO: MESSAGE

     PROGRAM:SOURCE-FILE-NAME:LINENO: MESSAGE

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

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

     PROGRAM: MESSAGE

     PROGRAM: MESSAGE

when there is no relevant source file.

when there is no relevant source file.

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

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

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

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

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

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

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

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

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

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

   The string MESSAGE should not begin with a capital letter when it

   The string MESSAGE should not begin with a capital letter when it

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

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

a period.

a period.

   Error messages from interactive programs, and other messages such as

   Error messages from interactive programs, and other messages such as

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

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

end with a period.

end with a period.

File: standards.info,  Node: User Interfaces,  Next: Option Table,  Prev: Errors,  Up: Program Behavior

File: standards.info,  Node: User Interfaces,  Next: Option Table,  Prev: Errors,  Up: Program Behavior

Standards for Command Line Interfaces

Standards for Command Line Interfaces

=====================================

=====================================

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

   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

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.

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

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

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

select among the alternate behaviors.

select among the alternate behaviors.

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

   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

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

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

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

to save someone from typing an option now and then.

to save someone from typing an option now and then.

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

   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

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

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

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

behavior.

behavior.

   Compatibility requires certain programs to depend on the type of

   Compatibility requires certain programs to depend on the type of

output device.  It would be disastrous if `ls' or `sh' did not do so in

output device.  It would be disastrous if `ls' or `sh' did not do so in

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

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

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

output device type.  For example, we provide a `dir' program much like

output device type.  For example, we provide a `dir' program much like

`ls' except that its default output format is always multi-column

`ls' except that its default output format is always multi-column

format.

format.

   It is a good idea to follow the POSIX guidelines for the

   It is a good idea to follow the POSIX guidelines for the

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

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

`getopt' to parse them.  Note that the GNU version of `getopt' will

`getopt' to parse them.  Note that the GNU version of `getopt' will

normally permit options anywhere among the arguments unless the special

normally permit options anywhere among the arguments unless the special

argument `--' is used.  This is not what POSIX specifies; it is a GNU

argument `--' is used.  This is not what POSIX specifies; it is a GNU

extension.

extension.

   Please define long-named options that are equivalent to the

   Please define long-named options that are equivalent to the

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

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

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

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

`getopt_long'.

`getopt_long'.

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

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

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

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

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

spelled precisely `--verbose'.  To achieve this uniformity, look at the

spelled precisely `--verbose'.  To achieve this uniformity, look at the

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

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

your program (*note Option Table::.).

your program (*note Option Table::.).

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

   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

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

options (preferably `-o' or `--output').  Even if you allow an output

options (preferably `-o' or `--output').  Even if you allow an output

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

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

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

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

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

   All programs should support two standard options: `--version' and

   All programs should support two standard options: `--version' and

`--help'.

`--help'.

`--version'

`--version'

     This option should direct the program to information about its

     This option should direct the program to information about its

     name, version, origin and legal status, all on standard output,

     name, version, origin and legal status, all on standard output,

     and then exit successfully.  Other options and arguments should be

     and then exit successfully.  Other options and arguments should be

     ignored once this is seen, and the program should not perform its

     ignored once this is seen, and the program should not perform its

     normal function.

     normal function.

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

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

     version number proper starts after the last space.  In addition,

     version number proper starts after the last space.  In addition,

     it contains the canonical name for this program, in this format:

     it contains the canonical name for this program, in this format:

          GNU Emacs 19.30

          GNU Emacs 19.30

     from `argv[0]'.  The idea is to state the standard or canonical

     from `argv[0]'.  The idea is to state the standard or canonical

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

     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 `PATH'.

     find out the precise file name where a command is found in `PATH'.

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

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

     the package name in parentheses, like this:

     the package name in parentheses, like this:

          emacsserver (GNU Emacs) 19.30

          emacsserver (GNU Emacs) 19.30

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

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

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

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

     number just before the close-parenthesis.

     number just before the close-parenthesis.

     If you *need* to mention the version numbers of libraries which

     If you *need* to mention the version numbers of libraries which

     are distributed separately from the package which contains this

     are distributed separately from the package which contains this

     program, you can do so by printing an additional line of version

     program, you can do so by printing an additional line of version

     info for each library you want to mention.  Use the same format

     info for each library you want to mention.  Use the same format

     for these lines as for the first line.

     for these lines as for the first line.

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

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

     "just for completeness"--that would produce a lot of unhelpful

     "just for completeness"--that would produce a lot of unhelpful

     clutter.  Please mention library version numbers only if you find

     clutter.  Please mention library version numbers only if you find

     in practice that they are very important to you in debugging.

     in practice that they are very important to you in debugging.

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

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

     be a copyright notice.  If more than one copyright notice is

     be a copyright notice.  If more than one copyright notice is

     called for, put each on a separate line.

     called for, put each on a separate line.

     Next should follow a brief statement that the program is free

     Next should follow a brief statement that the program is free

     software, and that users are free to copy and change it on certain

     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

     conditions.  If the program is covered by the GNU GPL, say so

     here.  Also mention that there is no warranty, to the extent

     here.  Also mention that there is no warranty, to the extent

     permitted by law.

     permitted by law.

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

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

     the program, as a way of giving credit.

     the program, as a way of giving credit.

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

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

          GNU Emacs 19.34.5

          GNU Emacs 19.34.5

          Copyright (C) 1996 Free Software Foundation, Inc.

          Copyright (C) 1996 Free Software Foundation, Inc.

          GNU Emacs comes with NO WARRANTY,

          GNU Emacs comes with NO WARRANTY,

          to the extent permitted by law.

          to the extent permitted by law.

          You may redistribute copies of GNU Emacs

          You may redistribute copies of GNU Emacs

          under the terms of the GNU General Public License.

          under the terms of the GNU General Public License.

          For more information about these matters,

          For more information about these matters,

          see the files named COPYING.

          see the files named COPYING.

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

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

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

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

     to distribution terms, and changing the rest of the wording as

     to distribution terms, and changing the rest of the wording as

     necessary.

     necessary.

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

     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

     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

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

     the program in these notices, if that is inconvenient, since it

     the program in these notices, if that is inconvenient, since it

     appeared in the first line.

     appeared in the first line.

`--help'

`--help'

     This option should output brief documentation for how to invoke the

     This option should output brief documentation for how to invoke the

     program, on standard output, then exit successfully.  Other

     program, on standard output, then exit successfully.  Other

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

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

     program should not perform its normal function.

     program should not perform its normal function.

     Near the end of the `--help' option's output there should be a line

     Near the end of the `--help' option's output there should be a line

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

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

          Report bugs to MAILING-ADDRESS.

          Report bugs to MAILING-ADDRESS.

File: standards.info,  Node: Option Table,  Next: Memory Usage,  Prev: User Interfaces,  Up: Program Behavior

File: standards.info,  Node: Option Table,  Next: Memory Usage,  Prev: User Interfaces,  Up: Program Behavior

Table of Long Options

Table of Long Options

=====================

=====================

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

   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

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,

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

please send  a list of them, with their meanings, so we

please send  a list of them, with their meanings, so we

can update the table.

can update the table.

`after-date'

`after-date'

     `-N' in `tar'.

     `-N' in `tar'.

`all'

`all'

     `-a' in `du', `ls', `nm', `stty', `uname', and `unexpand'.

     `-a' in `du', `ls', `nm', `stty', `uname', and `unexpand'.

`all-text'

`all-text'

     `-a' in `diff'.

     `-a' in `diff'.

`almost-all'

`almost-all'

     `-A' in `ls'.

     `-A' in `ls'.

`append'

`append'

     `-a' in `etags', `tee', `time'; `-r' in `tar'.

     `-a' in `etags', `tee', `time'; `-r' in `tar'.

`archive'

`archive'

     `-a' in `cp'.

     `-a' in `cp'.

`archive-name'

`archive-name'

     `-n' in `shar'.

     `-n' in `shar'.

`arglength'

`arglength'

     `-l' in `m4'.

     `-l' in `m4'.

`ascii'

`ascii'

     `-a' in `diff'.

     `-a' in `diff'.

`assign'

`assign'

     `-v' in `gawk'.

     `-v' in `gawk'.

`assume-new'

`assume-new'

     `-W' in Make.

     `-W' in Make.

`assume-old'

`assume-old'

     `-o' in Make.

     `-o' in Make.

`auto-check'

`auto-check'

     `-a' in `recode'.

     `-a' in `recode'.

`auto-pager'

`auto-pager'

     `-a' in `wdiff'.

     `-a' in `wdiff'.

`auto-reference'

`auto-reference'

     `-A' in `ptx'.

     `-A' in `ptx'.

`avoid-wraps'

`avoid-wraps'

     `-n' in `wdiff'.

     `-n' in `wdiff'.

`backward-search'

`backward-search'

     `-B' in `ctags'.

     `-B' in `ctags'.

`basename'

`basename'

     `-f' in `shar'.

     `-f' in `shar'.

`batch'

`batch'

     Used in GDB.

     Used in GDB.

`baud'

`baud'

     Used in GDB.

     Used in GDB.

`before'

`before'

     `-b' in `tac'.

     `-b' in `tac'.

`binary'

`binary'

     `-b' in `cpio' and `diff'.

     `-b' in `cpio' and `diff'.

`bits-per-code'

`bits-per-code'

     `-b' in `shar'.

     `-b' in `shar'.

`block-size'

`block-size'

     Used in `cpio' and `tar'.

     Used in `cpio' and `tar'.

`blocks'

`blocks'

     `-b' in `head' and `tail'.

     `-b' in `head' and `tail'.

`break-file'

`break-file'

     `-b' in `ptx'.

     `-b' in `ptx'.

`brief'

`brief'

     Used in various programs to make output shorter.

     Used in various programs to make output shorter.

`bytes'

`bytes'

     `-c' in `head', `split', and `tail'.

     `-c' in `head', `split', and `tail'.

`c++'

`c++'

     `-C' in `etags'.

     `-C' in `etags'.

`catenate'

`catenate'

     `-A' in `tar'.

     `-A' in `tar'.

`cd'

`cd'

     Used in various programs to specify the directory to use.

     Used in various programs to specify the directory to use.

`changes'

`changes'

     `-c' in `chgrp' and `chown'.

     `-c' in `chgrp' and `chown'.

`classify'

`classify'

     `-F' in `ls'.

     `-F' in `ls'.

`colons'

`colons'

     `-c' in `recode'.

     `-c' in `recode'.

`command'

`command'

     `-c' in `su'; `-x' in GDB.

     `-c' in `su'; `-x' in GDB.

`compare'

`compare'

     `-d' in `tar'.

     `-d' in `tar'.

`compat'

`compat'

     Used in `gawk'.

     Used in `gawk'.

`compress'

`compress'

     `-Z' in `tar' and `shar'.

     `-Z' in `tar' and `shar'.

`concatenate'

`concatenate'

     `-A' in `tar'.

     `-A' in `tar'.

`confirmation'

`confirmation'

     `-w' in `tar'.

     `-w' in `tar'.

`context'

`context'

     Used in `diff'.

     Used in `diff'.

`copyleft'

`copyleft'

     `-W copyleft' in `gawk'.

     `-W copyleft' in `gawk'.

`copyright'

`copyright'

     `-C' in `ptx', `recode', and `wdiff'; `-W copyright' in `gawk'.

     `-C' in `ptx', `recode', and `wdiff'; `-W copyright' in `gawk'.

`core'

`core'

     Used in GDB.

     Used in GDB.

`count'

`count'

     `-q' in `who'.

     `-q' in `who'.

`count-links'

`count-links'

     `-l' in `du'.

     `-l' in `du'.

`create'

`create'

     Used in `tar' and `cpio'.

     Used in `tar' and `cpio'.

`cut-mark'

`cut-mark'

     `-c' in `shar'.

     `-c' in `shar'.

`cxref'

`cxref'

     `-x' in `ctags'.

     `-x' in `ctags'.

`date'

`date'

     `-d' in `touch'.

     `-d' in `touch'.

`debug'

`debug'

     `-d' in Make and `m4'; `-t' in Bison.

     `-d' in Make and `m4'; `-t' in Bison.

`define'

`define'

     `-D' in `m4'.

     `-D' in `m4'.

`defines'

`defines'

     `-d' in Bison and `ctags'.

     `-d' in Bison and `ctags'.

`delete'

`delete'

     `-D' in `tar'.

     `-D' in `tar'.

`dereference'

`dereference'

     `-L' in `chgrp', `chown', `cpio', `du', `ls', and `tar'.

     `-L' in `chgrp', `chown', `cpio', `du', `ls', and `tar'.

`dereference-args'

`dereference-args'

     `-D' in `du'.

     `-D' in `du'.

`diacritics'

`diacritics'

     `-d' in `recode'.

     `-d' in `recode'.

`dictionary-order'

`dictionary-order'

     `-d' in `look'.

     `-d' in `look'.

`diff'

`diff'

     `-d' in `tar'.

     `-d' in `tar'.

`digits'

`digits'

     `-n' in `csplit'.

     `-n' in `csplit'.

`directory'

`directory'

     Specify the directory to use, in various programs.  In `ls', it

     Specify the directory to use, in various programs.  In `ls', it

     means to show directories themselves rather than their contents.

     means to show directories themselves rather than their contents.

     In `rm' and `ln', it means to not treat links to directories

     In `rm' and `ln', it means to not treat links to directories

     specially.

     specially.

`discard-all'

`discard-all'

     `-x' in `strip'.

     `-x' in `strip'.

`discard-locals'

`discard-locals'

     `-X' in `strip'.

     `-X' in `strip'.

`dry-run'

`dry-run'

     `-n' in Make.

     `-n' in Make.

`ed'

`ed'

     `-e' in `diff'.

     `-e' in `diff'.

`elide-empty-files'

`elide-empty-files'

     `-z' in `csplit'.

     `-z' in `csplit'.

`end-delete'

`end-delete'

     `-x' in `wdiff'.

     `-x' in `wdiff'.

`end-insert'

`end-insert'

     `-z' in `wdiff'.

     `-z' in `wdiff'.

`entire-new-file'

`entire-new-file'

     `-N' in `diff'.

     `-N' in `diff'.

`environment-overrides'

`environment-overrides'

     `-e' in Make.

     `-e' in Make.

`eof'

`eof'

     `-e' in `xargs'.

     `-e' in `xargs'.

`epoch'

`epoch'

     Used in GDB.

     Used in GDB.

`error-limit'

`error-limit'

     Used in `makeinfo'.

     Used in `makeinfo'.

`error-output'

`error-output'

     `-o' in `m4'.

     `-o' in `m4'.

`escape'

`escape'

     `-b' in `ls'.

     `-b' in `ls'.

`exclude-from'

`exclude-from'

     `-X' in `tar'.

     `-X' in `tar'.

`exec'

`exec'

     Used in GDB.

     Used in GDB.

`exit'

`exit'

     `-x' in `xargs'.

     `-x' in `xargs'.

`exit-0'

`exit-0'

     `-e' in `unshar'.

     `-e' in `unshar'.

`expand-tabs'

`expand-tabs'

     `-t' in `diff'.

     `-t' in `diff'.

`expression'

`expression'

     `-e' in `sed'.

     `-e' in `sed'.

`extern-only'

`extern-only'

     `-g' in `nm'.

     `-g' in `nm'.

`extract'

`extract'

     `-i' in `cpio'; `-x' in `tar'.

     `-i' in `cpio'; `-x' in `tar'.

`faces'

`faces'

     `-f' in `finger'.

     `-f' in `finger'.

`fast'

`fast'

     `-f' in `su'.

     `-f' in `su'.

`fatal-warnings'

`fatal-warnings'

     `-E' in `m4'.

     `-E' in `m4'.

`file'

`file'

     `-f' in `info', `gawk', Make, `mt', and `tar'; `-n' in `sed'; `-r'

     `-f' in `info', `gawk', Make, `mt', and `tar'; `-n' in `sed'; `-r'

     in `touch'.

     in `touch'.

`field-separator'

`field-separator'

     `-F' in `gawk'.

     `-F' in `gawk'.

`file-prefix'

`file-prefix'

     `-b' in Bison.

     `-b' in Bison.

`file-type'

`file-type'

     `-F' in `ls'.

     `-F' in `ls'.

`files-from'

`files-from'

     `-T' in `tar'.

     `-T' in `tar'.

`fill-column'

`fill-column'

     Used in `makeinfo'.

     Used in `makeinfo'.

`flag-truncation'

`flag-truncation'

     `-F' in `ptx'.

     `-F' in `ptx'.

`fixed-output-files'

`fixed-output-files'

     `-y' in Bison.

     `-y' in Bison.

`follow'

`follow'

     `-f' in `tail'.

     `-f' in `tail'.

`footnote-style'

`footnote-style'

     Used in `makeinfo'.

     Used in `makeinfo'.

`force'

`force'

     `-f' in `cp', `ln', `mv', and `rm'.

     `-f' in `cp', `ln', `mv', and `rm'.

`force-prefix'