The file contains login and initialization information used by the auto-login process. It resides in the user’s home directory. The following tokens are recognized; they may be separated by spaces, tabs, or newlines:
machine name Identify a remote machine name. The auto-login process searches the file for a machine token that matches the remote machine specified on the ftp command line or as an open command argument. When a match is made, the subsequent tokens are processed, stopping when the end of file is reached or another machine or a default token is encountered.
default This is the same as machine name except that default matches any name. There can be only one
default token, and it must be after all machine tokens. This is normally used as default login anonymous password user@site, thereby giving the user automatic anonymous ftp login to machines not specified. This can be overridden by using the -n flag to disable auto-login.
login name Identify a user on the remote machine. If this token is present, the auto-login process will initiate a login using the specified name.
password string Supply a password. If this token is present, the auto-login process will supply the specified string if the remote server requires a password as part of the login process. Note that if this token is present in the file for any user other than anonymous, ftp will abort the auto-login process if the is readable by anyone besides the user.
account string Supply an additional account password. If this token is present, the auto-login process will supply the specified string if the remote server requires an additional account password, or the auto-login process will initiate an ACCT command if it does not.
macdef name Define a macro. This token functions like the ftpmacdef command functions. A macro is defined with the specified name; its contents begin with the next line and continue until a null line (consecutive newline characters) is encountered. If a macro named init is defined, it is automati- cally executed as the last step in the auto-login process.
ENVIRONMENT
ftp utilizes the following environment variables:
HOME For default location of a file, if one exists
SHELL For default shell
SEE ALSO
ftpd(8)
HISTORY
The ftp command appeared in BSD 4.2.
BUGS
Correct execution of many commands depends upon proper behavior by the remote server.
An error in the treatment of carriage returns in the BSD 4.2 ASCII-mode transfer code has been corrected. This correction may result in incorrect transfers of binary files to and from BSD 4.2 servers using the ASCII type. Avoid this problem by using the binary image type.
BSD 4.2, 30 July 1991
fuser
fuser—Identify processes using files
SYNOPSIS
fuser [–a|–s][–signal][–kmuv] filename ... [–][–signal][–kmuv] filename ... fuser [–l]
DESCRIPTION
fuser displays the PIDs of processes using the specified files or file systems. In the default display mode, each filename is followed by a letter denoting the type of access:
c Current directory.
e Executable being run.
f Open file. f is omitted in default display mode.
r Root directory.
m mmap’ed file or shared library.
fuser returns a nonzero return code if none of the specified files is accessed or in case of a fatal error. If at least one access has been found, fuser returns zero.
OPTIONS
–a Show all files specified on the command line. By default, only files that are accessed by at least one process are shown.
–k Kill processes accessing the file. Unless changed with -signal, SIGKILL is sent. A fuser process never kills itself, but may kill other fuser processes.
u List all known signal names.
–m filename specifies a file on a mounted file system or a block device that is mounted. All processes accessing files on that file system are listed. If a directory file is specified, it is automatically changed to filename/. to use any file system that might be mounted on that directory.
–s Silent operation. –a, –u, and –v are ignored in this mode.
–signal Use the specified signal instead of SIGKILL when killing processes. Signals can be specified either by name (for example, –HUP) or by number (for example, –1).
–u Append the username of the process owner to each PID.
–v Verbose mode. Processes are shown in a ps-like style. The fields PID, USER, and COMMAND are similar to ps.
ACCESS shows how the process accesses the file.
– Reset all options and set the signal back to SIGKILL.
FILES
/proc Location of the proc file system
EXAMPLES
fuser -km /home kills all processes accessing the file system /home in any way.
In this example:
if fuser -s /dev/ttyS1; then :; else something
fi invokes something if no other process is using /dev/ttyS1.
RESTRICTIONS
Processes accessing the same file or filesystem several times in the same way are only shown once.
AUTHOR
Werner Almesberger (<[email protected]>U)
SEE ALSO
kill(1), killall(1), ps(1), kill(2) Linux, 11 October 1994
g++
g++—GNU project C++ Compiler
SYNOPSIS
g++ [ option | filename ]. ..
DESCRIPTION
The C and C++ compilers are integrated; g++ is a script to call gcc with options to recognize C++. gcc processes input files through one or more of four stages: preprocessing, compilation, assembly, and linking. This man page contains full descriptions for only C++ specific aspects of the compiler, though it also contains summaries of some general-purpose options. For a fuller explanation of the compiler, see gcc(1).
C++ source files use one of the suffixes .C, .cc, .cxx, .cpp, or .c++; preprocessed C++ files use the suffix .ii.
OPTIONS
There are many command-line options, including options to control details of optimization, warnings, and code generation, which are common to both gcc and g++. For full information on all options, see gcc(1).
Options must be separate: –dr is quite different from –d -r.
Most –f and –W options have two contrary forms: –fname and –fno–name (or –Wname and –Wno–name). Only the nondefault forms are shown here.
–c Compile or assemble the source files, but do not link. The compiler output is an object file corresponding to each source file.
–Dmacro Define macro macro with the string 1 as its definition.
–Dmacro=defn Define macro macro as defn.
–E Stop after the preprocessing stage; do not run the compiler proper. The output is preprocessed source code, which is sent to the standard output.
–fall–virtual Treat all possible member functions as virtual, implicitly. All member functions (except for constructor functions and new or delete member operators) are treated as virtual functions of the class where they appear.
This does not mean that all calls to these member functions will be made through the internal table of virtual functions. Under some circumstances, the compiler can determine that a call to a given virtual function can be made directly; in these cases the calls are direct in any case.
–fdollars–in–identifiers Permit the use of $ in identifiers. Traditional C allowed the character $ to form part of identifiers; by default, GNU C also allows this. However, ANSI C forbids $ in identifiers, and GNU C++ also forbids it by default on most platforms (though on some platforms it’s enabled by default for GNU C++ as well).
–felide–constructors Use this option to instruct the compiler to be smarter about when it can elide constructors. Without this flag, GNU C++ and cfront both generate effectively the same code for
A foo ();
A x (foo ()); // x initialized by ‘foo ()’, no ctor called
A y = foo (); // call to ‘foo ()’ heads to temporary, // y is initial- ized from the temporary.
Note the difference. With this flag, GNU C++ initializes y directly from the call to
foo() without going through a temporary.
–fenum–int–equiv Normally GNU C++ allows conversion of enum to int, but not the other way around. Use this option if you want GNU C++ to allow conversion of int to enum as well.
–fexternal–templates Produce smaller code for template declarations, by generating only a single copy of each template function where it is defined. To use this option successfully, you must also mark all files that use templates with either #pragma implementation (the definition) or #pragma interface (declarations).
When your code is compiled with –fexternal–templates, all template instantiations are external. You must arrange for all necessary instantiations to appear in the implementation file; you can do this with a typedef that references each instantiation needed. Conversely, when you compile using the default option –fno– external– templates, all template instantiations are explicitly internal.
–fno–gnu–linker Do not output global initializations (such as C++ constructors and destructors) in the form used by the GNU linker (on systems where the GNU linker is the standard method of handling them). Use this option when you want to use a non-GNU linker, which also requires using the collect2 program to make sure the system linker includes constructors and destructors. (collect2 is included in the GNU CC distribution.) For systems which must use collect2, the compiler driver gcc is configured to do this automatically.
–fmemoize–lookups–fsave–memorized These flags are used to get the compiler to compile programs faster using heuristics. They are not on by default since they are only effective about half the time. The other half of the time programs compile more slowly (and take more memory).
The first time the compiler must build a call to a member function (or reference to a data member), it must (1) determine whether the class implements member functions of that name; (2) resolve which member function to call (which involves figuring out what sorts of type conversions need to be made); and (3) check the visibility of the member function to the caller. All of this adds up to slower compilation. Normally, the second time a call is made to that member function (or reference to that data member), it must go through the same lengthy process again. This means that code like this:
cout << “This “ << p << “has”<< n << “ legs.\n”;
makes six passes through all three steps. By using a software cache, a “hit” signifi- cantly reduces this cost. Unfortunately, using the cache introduces another layer of mechanisms which must be implemented, and so incurs its own overhead. – fmemorize– lookups enables the software cache.
Because access privileges (visibility) to members and member functions may differ from one function context to the next, g++ may need to flush the cache. With the – fmemoize–lookups flag, the cache is flushed after every function that is compiled. The
–fsave–memorized flag enables the same software cache, but when the compiler determines that the context of the last function compiled would yield the same access privileges of the next function to compile, it preserves the cache. This is most helpful when defining many member functions for the same class: with the exception of member functions which are friends of other classes, each member function has exactly the same access privileges as every other, and the cache need not be flushed.
–fno–default–inline Do not make member functions inline by default merely because they are defined inside the class scope. Otherwise, when you specify –O, member functions defined inside class scope are compiled inline by default; that is, you don’t need to add
inline in front of the member function name.
–fno–strict–prototype Consider the declaration intfoo;(). In C++, this means that the function foo takes no arguments. In ANSI C, this is declared int foo(void);. With the flag –fno– strict–prototype, declaring functions with no arguments is equivalent to declaring its argument list to be untyped, that is, int foo(); is equivalent to saying int foo (...);.–fnonnull–objects. Normally, GNU C++ makes conservative assumptions about objects reached through references. For example, the compiler must check that
a is not null in code like the following:
obj &a = g (); a.f (2);
Checking that references of this sort have non-null values requires extra code, however, and it is unnecessary for many programs. You can use –fnonnull–objects to omit the checks for null, if your program doesn’t require the default checking.
–fhandle–signatures– These options control the recognition of the signature and sigof constructs for
fno–handle–signatures specifying abstract types. By default, these constructs are not recognized.
–fthis–is–variable The incorporation of user-defined free store management into C++ has made assignment to this an anachronism. Therefore, by default GNU C++ treats the type of this in a member function of class X to be X *const. In other words, it is illegal to assign to this within a class member function. However, for backwards compatibil- ity, you can invoke the old behavior by using –fthis–is–variable.
–g Produce debugging information in the operating system’s native format (for DBX or SDB or DWARF). GDB also can work with this debugging information. On most systems that use DBX format, –g enables use of extra debugging information that only GDB can use.
Unlike most other C compilers, GNU CC allows you to use –g with –0. The shortcuts taken by optimized code may occasionally produce surprising results: some
variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless, it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.
–Idir Append directory dir to the list of directories searched for include files.
–Ldir Add directory dir to the list of directories to be searched for –l.
–llibrary Use the library named library when linking. (C++ programs often require –lg++ for successful linking.)
–nostdinc Do not search the standard system directories for header files. Only the directories you have specified with –I options (and the current directory, if appropriate) are searched.
–nostdinc++ Do not search for header files in the standard directories specific to C++, but do still search the other standard directories. (This option is used when building libg++.) –O Optimize. Optimizing compilation takes somewhat more time, and a lot more
memory for a large function.
–o file Place output in file file.
–S Stop after the stage of compilation proper; do not assemble. The output is an assembler code file for each nonassembler input file specified.
–traditional Attempt to support some aspects of traditional C compilers. Specifically, for both C and C++ programs:
In the preprocessor, comments convert to nothing at all, rather than to a space. This allows traditional token concatenation.
In the preprocessor, macro arguments are recognized within string constants in a macro definition (and their values are stringified, though without additional quote marks, when they appear in such a context). The preprocessor always considers a string constant to end at a newline.
The preprocessor does not predefine the macro STDC when you use –traditional, but still predefines GNUC (since the GNU extensions indicated by GNUC are not affected by
–traditional). If you need to write header files that work differently depending on whether –traditional is in use, by testing both of these predefined macros you can distinguish four situations: GNU C, traditional GNU C, other ANSI C compilers, and other old C compilers.
In the preprocessor, comments convert to nothing at all, rather than to a space. This allows traditional token concatenation.
String “constants” are not necessarily constant; they are stored in writable space, and identical looking constants are allocated separately. For C++ programs only (not C),
–traditional has one additional effect: assignment to this is permitted. This is the same as the effect of –fthis–is–variable.
–Umacro Undefine macro macro.
–Wall Issue warnings for conditions that pertain to usage that we recommend avoiding and that we believe is easy to avoid, even in conjunction with macros.
–Wenum–clash Warn when converting between different enumeration types.
–Woverloaded–virtual In a derived class, the definitions of virtual functions must match the type signature of a virtual function declared in the base class. Use this option to request warnings when a derived class declares a function that may be an erroneous attempt to define a virtual function; that is, warn when a function with the same name as a virtual function in the base class, but with a type signature that doesn’t match any virtual functions from the base class.
–Wtemplate–debugging When using templates in a C++ program, warn if debugging is not yet fully available.
–w Inhibit all warning messages.
+eN Control how virtual function definitions are used, in a fashion compatible with
cfront 1.x.
PRAGMAS
Two #pragma directives are supported for GNU C++, to permit using the same header file for two purposes: as a definition of
interfaces to a given object class, and as the full definition of the contents of that object class.
#pragma interface Use this directive in header files that define object classes, to save space in most of the object files that use those classes. Normally, local copies of certain information (backup copies of inline member functions, debugging information, and the internal tables that implement virtual functions) must be kept in each object file that includes class definitions. You can use this pragma to avoid such duplication. When a header file containing #pragma interface is included in a compilation, this auxiliary information will not be generated (unless the main input source file itself uses
#pragma implementation). Instead, the object files will contain references to be resolved at link time.
#pragma implementation Use this pragma in a main input file, when you want full output from included
#pragma implementation !objects.h! header files to be generated (and made globally visible). The included header file, in turn, should use #pragma interface. Backup copies of inline member functions, debugging information, and the internal tables used to implement virtual functions are all generated in implementation files.
If you use #pragma implementation with no argument, it applies to an include file with the same basename as your source file; for example, in allclass.cc, #pragma implementation by itself is equivalent to #pragma implementation “allclass.h”. Use the string argument if you want a single implementation file to include code from multiple header files.
There is no way to split up the contents of a single header file into multiple