Lines Matching full:program
45 * Design Advice:: General program design.
46 * Program Behavior:: Program behavior for all programs
102 to document them as much as possible. That way, your program will be
105 The GNU Hello program serves as an example of how to follow the GNU
106 coding standards for a trivial program.
136 If you have a vague recollection of the internals of a Unix program,
143 memory use; if you go for speed instead, your program will be very
146 recently than the Unix program. Eliminate use of temporary files. Do
155 dynamic allocation instead. Make sure your program handles NULs and
157 for extensibility and write part of the program in that language.
159 Or turn some parts of the program into independently usable
170 If the program you are working on is copyrighted by the Free Software
172 the program, we need legal papers to use it--just as we asked you to
174 contribution to a program must sign some sort of legal papers in order
175 for us to have clear title to the program; the main author alone is not
183 This applies both before you release the program and afterward. If
208 reached the stage of actually maintaining a program for GNU (whether
246 File: standards.info, Node: Design Advice, Next: Program Behavior, Prev: Legal Issues, Up: Top
248 3 General Program Design
252 when designing your program.
273 program. For example, if you write your program in C++, people will
274 have to install the GNU C++ compiler in order to compile your program.
278 program if it is written in C.
297 the program is written in that language, too. The Emacs editor
331 defined with a null value). Please make your program recognize this
351 extensions in implementing your program is a difficult question.
353 On the one hand, using the extensions can make a cleaner program.
354 On the other hand, people will not be able to build the program unless
355 the other GNU tools are available. This might cause the program to
393 programs, so if you know how to do that, feel free. If a program you
450 program we prefer using `if (... )' over conditional compilation, as in
490 File: standards.info, Node: Program Behavior, Next: Writing C, Prev: Design Advice, Up: Top
492 4 Program Behavior for All Programs
515 File: standards.info, Node: Non-GNU Standards, Next: Semantics, Up: Program Behavior
522 "obey" them. In developing a GNU program, you should implement an
529 specified by that standard. C program developers would be unhappy if
562 File: standards.info, Node: Semantics, Next: Libraries, Prev: Non-GNU Standards, Up: Program Behavior
594 run your program on Unix, and wish to avoid lossage in this case, you
601 If `malloc' fails in a noninteractive program, make that a fatal
602 error. In an interactive program (one that reads commands from the
610 When static storage is to be written in during program execution, use
625 make a program portable. If you use `signal', then on GNU/Linux
639 Do not use a count of errors as the exit status for a program.
641 (0 through 255). A single run of the program might have 256 errors; if
643 as the status, and it will appear that the program succeeded.
660 File: standards.info, Node: Libraries, Next: Errors, Prev: Semantics, Up: Program Behavior
678 together, so that no reasonable program could use one without the
691 File: standards.info, Node: Errors, Next: User Interfaces, Prev: Libraries, Up: Program Behavior
727 PROGRAM:SOURCE-FILE-NAME:LINENO: MESSAGE
731 PROGRAM: MESSAGE
737 PROGRAM:SOURCE-FILE-NAME:LINENO:COLUMN: MESSAGE
739 In an interactive program (one that is reading commands from a
740 terminal), it is better not to include the program name in an error
741 message. The place to indicate which program is running is in the
742 prompt or with the screen layout. (When the same program runs with
747 follows a program name and/or file name, because that isn't the
756 File: standards.info, Node: User Interfaces, Next: Graphical Interfaces, Prev: Errors, Up: Program Behavior
768 Likewise, please don't make the behavior of the program depend on the
784 program with a preferred alternate version that does not depend on the
785 output device type. For example, we provide a `dir' program much like
790 File: standards.info, Node: Graphical Interfaces, Next: Command-Line Interfaces, Prev: User Interfaces, Up: Program Behavior
795 When you write a program that provides a graphical user interface,
802 separate program which invokes the command-line program.) This is so
814 File: standards.info, Node: Command-Line Interfaces, Next: Option Table, Prev: Graphical Interfaces, Up: Program Behavior
820 options of a program. The easiest way to do this is to use `getopt' to
831 consistent from program to program. For example, users should be able
832 to expect the "verbose" option of any GNU program which has one, to be
835 your program (*note Option Table::).
861 The standard `--version' option should direct the program to print
864 arguments should be ignored once this is seen, and the program should
867 The first line is meant to be easy for a program to parse; the
869 contains the canonical name for this program, in this format:
873 The program's name should be a constant string; _don't_ compute it from
875 program, not its file name. There are other ways to find out the
878 If the program is a subsidiary part of a larger package, mention the
884 program's version number, you can mention the package version number
888 distributed separately from the package which contains this program,
893 Please do not mention all of the libraries that the program uses
903 of abbrevations below, and a brief statement that the program is free
909 program, as a way of giving credit.
919 You should adapt this to your program, of course, filling in the
920 proper year, copyright holder, name of program, and the references to
925 versions' changes. You don't have to mention the name of the program in
1010 to invoke the program, on standard output, then exit successfully.
1012 the program should not perform its normal function.
1026 File: standards.info, Node: Option Table, Next: OID Allocations, Prev: Command-Line Interfaces, Up: Program Behavior
1032 incomplete, but we aim to list all the options that a new program might
1804 Used in many programs to inhibit the usual output. Every program
1916 Used in many programs to inhibit the usual output. Every program
2117 File: standards.info, Node: OID Allocations, Next: Memory Usage, Prev: Option Table, Up: Program Behavior
2170 File: standards.info, Node: Memory Usage, Next: File Usage, Prev: OID Allocations, Up: Program Behavior
2175 If a program typically uses just a few meg of memory, don't bother
2184 program works by lines and could be applied to arbitrary user-supplied
2189 If your program creates complicated data structures, just make them
2193 File: standards.info, Node: File Usage, Prev: Memory Usage, Up: Program Behavior
2199 read-only file systems. Thus, if the program manages log files, lock
2205 configuration information; it is reasonable for a program to modify
2208 is reasonable for the program to store other files in the same
2212 File: standards.info, Node: Writing C, Next: Documentation, Prev: Program Behavior, Up: Top
2281 program in version 1.2 and newer. It corresponds to the options
2291 program tends to look ugly. If you are
2292 contributing changes to an existing program, please follow the style of
2293 that program.
2309 We find it easier to read a program when it has spaces before the
2352 Please use formfeed characters (control-L) to divide the program into
2363 Every program should start with a comment saying briefly what it is for.
2366 of the program.
2372 Please write the comments in a GNU program in English, because
2473 all its uses. This makes the program even cleaner.
2552 Don't make the program ugly to placate `lint'. Please don't insert
2562 The names of global variables and functions in a program serve as
2565 function. In a GNU program, names should be English, like other
2596 shortens the names. You can use the program `doschk' to test for this.
2612 versions. For a GNU program, this kind of portability is desirable, but
2629 to use Autoconf. It's unlikely that your program needs to know more
2656 the same function names in some other way in your program. (You don't
2658 program more portable to other systems.)
2729 If STATUS is nonzero, terminate the program with `exit (STATUS)'. */
2807 Because `xmalloc' and `xrealloc' are defined in your program, you
2855 program. (Nowadays, it is better to choose `strchr' and `strrchr'
2884 messages in a program into various languages. You should use this
2885 library in every program. Use English for the messages as they appear
2886 in the program, and let gettext provide the way to translate them into
2897 Once a program uses gettext, please make a point of writing calls to
3010 In any case, the documentation for your program should clearly
3013 program is ever likely to be parsed by another program.
3052 A GNU program should ideally come with full free documentation, adequate
3095 Programmers tend to carry over the structure of the program as the
3097 good for explaining how to use the program; it may be irrelevant and
3111 For example, each program in the GNU system probably ought to be
3112 documented in one manual; but this does not mean each program should
3123 The manual which discusses a program should certainly document all of
3124 the program's command-line options and all of its commands. It should
3128 program does. Don't just tell the reader what each feature can do--say
3155 of the program. One combined Index should do for a short manual, but
3175 a computer program. Please use "invalid" for this, and reserve the
3221 frequently than or independent of the program, also state a version
3224 Each program documented in the manual should have a node named
3225 `PROGRAM Invocation' or `Invoking PROGRAM'. This node (together with
3226 its subnodes, if any) should describe the program's command line
3229 all the options and arguments that the program uses.
3240 for each program described in the manual.
3259 can be a good idea to include the program's license in a large manual;
3261 including the program's license, it is probably better not to include
3314 Keep a change log to describe all the changes made to program source
3319 inconsistencies between different parts of a program, by giving you a
3465 enough to compare what the documentation says with the way the program
3529 expected for every GNU program to have a man page, but some of them do.
3530 It's your choice whether to include a man page in your program.
3533 requires continual effort each time the program is changed. The time
3536 For a simple program which changes little, updating the man page may
3540 For a large program that changes a great deal, updating a man page
3549 When a program changes only a little, you may feel that the
3565 Finally, the GNU help2man program
3577 program you are documenting.
3582 a certain program works, and these facts are necessarily the same for
3616 machine and system you want to compile the program for. The
3632 that people won't be able to build the program without configuring it
3639 won't be able to build the program without configuring it first.
3653 program was last configured. This file should be a shell script which,
3659 program in a separate directory, so that the actual source directory is
3684 the type of system to build the program for. This argument should look
3722 `--enable' is for questions of whether to build part of the program
3765 program may be different.
3768 system as both the host and the target, thus producing a program which
3771 To compile a program to run on a host type that differs from the
3789 your program is set up to do this, your `configure' script can simply
3840 make, please make sure that it uses `./' if the program is built as
3887 program in ordinary circumstances should not modify the source directory
3909 The compression program `gzip' can be used in the `dist' rule.
3932 bad happens if the system does not have the program in question.
3966 Each program-name variable should come with an options variable that
3967 is used to supply options to the program. Append `FLAGS' to the
3968 program-name variable name to get the options variable name--for
4103 one used to build the program should _not_ recompile the program.
4117 from the one used to build the program should _not_ recompile the
4118 program.
4148 Data files used by the program during its execution are divided into
4177 architecture-independent data files for this program. This is
4179 separate variables so that you can move these program-specific
4222 types of files, if your program has them. Every GNU package should
4223 have Info files, so every program needs `infodir', but not all need
4373 If your program installs a large number of files into one of the
4375 into a subdirectory particular to that program. If you do this, you
4402 Compile the entire program. This should be the default target.
4413 Compile the program and copy the executables, libraries, and so on
4415 there is a simple test to verify that a program is properly
4422 modify anything in the directory where the program was built,
4424 building the program under one user name and installing it under
4440 the `install-info' program if it is present. `install-info' is a
4441 program that edits the Info `dir' file to add or update the menu
4518 are sure the program has no bugs. However, it can be reasonable
4524 created by building the program. Also delete files in other
4536 makefile) that are created by configuring or building the program.
4537 If you have unpacked the source and built the program without
4560 the program. Also, there is no need to delete parent directories
4580 Update a tags table for this program.
4592 run the `makeinfo' program, which is part of the Texinfo
4619 run the program `texi2dvi', which is part of the Texinfo
4635 Create a distribution tar file for this program. The tar file
4655 Perform self-tests (if any). The user must build the program
4656 before running the tests, but need not install the program; you
4657 should write the self-tests so that they work when the program is
4665 install the program before running the tests. You should not
4818 Building and installing the program should never modify any of the
4820 that form part of the program in any way must be classified into "source
4849 installing the program should *never* be included in the distribution.
4877 Likewise, if your program uses small GNU software packages like
4889 A GNU program should not recommend, promote, or grant legitimacy to the
4890 use of any non-free program. Proprietary software is a social and
4909 When a non-free program or system is well known, you can mention it
4914 program.
4917 who already use the non-free program to use your program with it--don't
4919 program, and don't imply that the proprietary program enhances your
4920 program, or that its existence is in any way a good thing. The goal
4921 should be that people already using the proprietary program will get
4922 the advice they need about how to use your free program with it, while
4923 people who don't already use the proprietary program will not see
4926 program or system is obscure in your program's domain,
4927 your program should not mention or support it at all, since doing so
4928 would tend to popularize the non-free program more than it popularizes
4929 your program. (You cannot hope to find many additional users for your
4930 program among the users of Foobar, if the existence of Foobar is not
4931 generally known among people who might want to use your program.)
4933 Sometimes a program is free software in itself but depends on a
4936 program is to promote the other programs it needs. This is why we are
4967 the comments of a program for explanation of how it functions, even
4973 program is promoting that program, so please do not make links (or
4980 the site does not itself recommend a non-free program, there is no need
4987 non-free program, because that link recommends and legitimizes the
4988 non-free program. However, that a site contains a link to AT&T's web
5023 free program should come with manuals providing the same freedoms
5473 If your document contains nontrivial examples of program code, we
5500 * behavior, dependent on program's name: User Interfaces. (line 6)
5507 * canonical name of a program: --version. (line 12)
5621 * output device and program's behavior: User Interfaces. (line 13)
5635 * program configuration: Configuration. (line 6)
5636 * program design: Design Advice. (line 6)
5637 * program name and its behavior: User Interfaces. (line 6)
5638 * program's canonical name: --version. (line 12)
5686 Node: Program Behavior20646
