From 98dfb87d06cad8784ac9e3d009f8dcae4cce4c38 Mon Sep 17 00:00:00 2001 From: Jakub Bogusz Date: Tue, 18 Aug 2020 21:19:47 +0200 Subject: [PATCH] - drop C version of rpcgen.1 man page (newer version is included in rpcsvc-proto package) --- man-pages-extra-files.patch | 437 ------------------------------------ 1 file changed, 437 deletions(-) diff --git a/man-pages-extra-files.patch b/man-pages-extra-files.patch index 22c3675..863faac 100644 --- a/man-pages-extra-files.patch +++ b/man-pages-extra-files.patch @@ -7058,443 +7058,6 @@ + +.SH TRADUCTION +Frédéric Delanoy, 2000. ---- man-pages-extra.orig/man1/rpcgen.1 1970-01-01 01:00:00.000000000 +0100 -+++ man-pages-extra/man1/rpcgen.1 2002-04-21 11:17:39.000000000 +0200 -@@ -0,0 +1,434 @@ -+.\" @(#)rpcgen.new.1 1.1 90/11/09 TIRPC 1.0; from 40.10 of 10/10/89 -+.\" Copyright (c) 1988,1990 Sun Microsystems, Inc. - All Rights Reserved. -+.nr X -+.if \nX=0 .ds x} rpcgen 1 "" "\&" -+.if \nX=1 .ds x} rpcgen 1 "" -+.if \nX=2 .ds x} rpcgen 1 "" "\&" -+.if \nX=3 .ds x} rpcgen "" "" "\&" -+.TH \*(x} -+.SH NAME -+\f4rpcgen\f1 \- an RPC protocol compiler -+.SH SYNOPSIS -+.ft 4 -+.nf -+rpcgen \f2infile\f4 -+.fi -+.ft 1 -+.br -+.ft 4 -+.nf -+rpcgen [\-D\f2name\f4[=\f2value\f4]] [\-T] [\-K \f2secs\fP] \f2infile\f4 -+.fi -+.ft 1 -+.br -+.ft 4 -+.nf -+rpcgen \-c|\-h|\-l|\-m|\-t [\-o \f2outfile\f4 ] \f2infile\f4 -+.fi -+.ft 1 -+.br -+.ft 4 -+.nf -+rpcgen [\-I] \-s \f2nettype\f4 [\-o \f2outfile\f4] \f2infile\f4 -+.fi -+.ft 1 -+.br -+.ft 4 -+.nf -+rpcgen \-n \f2netid\f4 [\-o \f2outfile\f4] \f2infile\f4 -+.ft 1 -+.SH DESCRIPTION -+.P -+\f4rpcgen\f1 -+is a tool that generates C code to implement an RPC protocol. -+The input to -+\f4rpcgen\f1 -+is a language similar to C known as -+RPC Language (Remote Procedure Call Language). -+.P -+\f4rpcgen\f1 -+is normally used as in the first synopsis where -+it takes an input file and generates up to four output files. -+If the -+\f2infile\f1 -+is named -+\f4proto.x\f1, -+then -+\f4rpcgen\f1 -+will generate a header file in -+\f4proto.h\f1, -+XDR routines in -+\f4proto_xdr.c\f1, -+server-side stubs in -+\f4proto_svc.c\f1, -+and client-side stubs in -+\f4proto_clnt.c\f1. -+With the -+\f4\-T\f1 -+option, -+it will also generate the RPC dispatch table in -+\f4proto_tbl.i\f1. -+With the -+\f4\-Sc\f1 -+option, -+it will also generate sample code which would illustrate how to use the -+remote procedures on the client side. This code would be created in -+\f4proto_client.c\f1. -+With the -+\f4\-Ss\f1 -+option, -+it will also generate a sample server code which would illustrate how to write -+the remote procedures. This code would be created in -+\f4proto_server.c\f1. -+.P -+The server created can be started both by the port monitors -+(for example, \f4inetd\f1 or \f4listen\f1) -+or by itself. -+When it is started by a port monitor, -+it creates servers only for the transport for which -+the file descriptor \f40\fP was passed. -+The name of the transport must be specified -+by setting up the environmental variable -+\f4PM_TRANSPORT\f1. -+When the server generated by -+\f4rpcgen\f1 -+is executed, -+it creates server handles for all the transports -+specified in -+\f4NETPATH\f1 -+environment variable, -+or if it is unset, -+it creates server handles for all the visible transports from -+\f4/etc/netconfig\f1 -+file. -+Note: -+the transports are chosen at run time and not at compile time. -+When the server is self-started, -+it backgrounds itself by default. -+A special define symbol -+\f4RPC_SVC_FG\f1 -+can be used to run the server process in foreground. -+.P -+The second synopsis provides special features which allow -+for the creation of more sophisticated RPC servers. -+These features include support for user provided -+\f4#defines\f1 -+and RPC dispatch tables. -+The entries in the RPC dispatch table contain: -+.RS -+.PD 0 -+.TP 3 -+\(bu -+pointers to the service routine corresponding to that procedure, -+.TP -+\(bu -+a pointer to the input and output arguments -+.TP -+\(bu -+the size of these routines -+.PD -+.RE -+A server can use the dispatch table to check authorization -+and then to execute the service routine; -+a client library may use it to deal with the details of storage -+management and XDR data conversion. -+.P -+The other three synopses shown above are used when -+one does not want to generate all the output files, -+but only a particular one. -+Some examples of their usage is described in the -+EXAMPLE -+section below. -+When -+\f4rpcgen\f1 -+is executed with the -+\f4\-s\f1 -+option, -+it creates servers for that particular class of transports. -+When -+executed with the -+\f4\-n\f1 -+option, -+it creates a server for the transport specified by -+\f2netid\f1. -+If -+\f2infile\f1 -+is not specified, -+\f4rpcgen\f1 -+accepts the standard input. -+.P -+The C preprocessor, -+\f4cc \-E\f1 -+[see \f4cc\fP(1)], -+is run on the input file before it is actually interpreted by -+\f4rpcgen\f1. -+For each type of output file, -+\f4rpcgen\f1 -+defines a special preprocessor symbol for use by the -+\f4rpcgen\f1 -+programmer: -+.P -+.PD 0 -+.TP 12 -+\f4RPC_HDR\f1 -+defined when compiling into header files -+.TP -+\f4RPC_XDR\f1 -+defined when compiling into XDR routines -+.TP -+\f4RPC_SVC\f1 -+defined when compiling into server-side stubs -+.TP -+\f4RPC_CLNT\f1 -+defined when compiling into client-side stubs -+.TP -+\f4RPC_TBL\f1 -+defined when compiling into RPC dispatch tables -+.PD -+.P -+Any line beginning with -+`\f4%\f1' -+is passed directly into the output file, -+uninterpreted by -+\f4rpcgen\f1. -+.P -+For every data type referred to in -+\f2infile\f1, -+\f4rpcgen\f1 -+assumes that there exists a -+routine with the string -+\f4xdr_\f1 -+prepended to the name of the data type. -+If this routine does not exist in the RPC/XDR -+library, it must be provided. -+Providing an undefined data type -+allows customization of XDR routines. -+.br -+.ne 10 -+.P -+The following options are available: -+.TP -+\f4\-a\f1 -+Generate all the files including sample code for client and server side. -+.TP -+\f4\-b\f1 -+This generates code for the SunOS4.1 style of rpc. It is -+for backward compatibilty. This is the default. -+.TP -+\f4\-5\f1 -+This generates code for the SysVr4 style of rpc. It is used by the -+Transport Independent RPC that is in Svr4 systems. -+By default rpcgen generates code for SunOS4.1 stype of rpc. -+.TP -+\f4\-c\f1 -+Compile into XDR routines. -+.TP -+\f4\-C\f1 -+Generate code in ANSI C. This option also generates code that could be -+compiled with the C++ compiler. This is the default. -+.TP -+\f4\-k\f1 -+Generate code in K&R C. The default is ANSI C. -+.TP -+\f4\-D\f2name\f4[=\f2value\f4]\f1 -+Define a symbol -+\f2name\f1. -+Equivalent to the -+\f4#define\f1 -+directive in the source. -+If no -+\f2value\f1 -+is given, -+\f2value\f1 -+is defined as \f41\f1. -+This option may be specified more than once. -+.TP -+\f4\-h\f1 -+Compile into -+\f4C\f1 -+data-definitions (a header file). -+\f4\-T\f1 -+option can be used in conjunction to produce a -+header file which supports RPC dispatch tables. -+.TP -+\f4\-I\f1 -+Generate a service that can be started from inetd. The default is -+to generate a static service that handles transports selected with \f4\-s\f1. -+Using \f4\-I\f1 allows starting a service by either method. -+.TP -+\f4-K\f2 secs\f1 -+By default, services created using \f4rpcgen\fP wait \f4120\fP seconds -+after servicing a request before exiting. -+That interval can be changed using the \f4-K\fP flag. -+To create a server that exits immediately upon servicing a request, -+\f4-K\ 0\fP can be used. -+To create a server that never exits, the appropriate argument is -+\f4-K\ -1\fP. -+.IP -+When monitoring for a server, -+some portmonitors, like -+\f4listen\fP(1M), -+.I always -+spawn a new process in response to a service request. -+If it is known that a server will be used with such a monitor, the -+server should exit immediately on completion. -+For such servers, \f4rpcgen\fP should be used with \f4-K\ -1\fP. -+.TP -+\f4\-l\f1 -+Compile into client-side stubs. -+.TP -+\f4\-m\f1 -+Compile into server-side stubs, -+but do not generate a \(lqmain\(rq routine. -+This option is useful for doing callback-routines -+and for users who need to write their own -+\(lqmain\(rq routine to do initialization. -+.TP -+\f4\-n \f2netid\f1 -+Compile into server-side stubs for the transport -+specified by -+\f2netid\f1. -+There should be an entry for -+\f2netid\f1 -+in the -+netconfig database. -+This option may be specified more than once, -+so as to compile a server that serves multiple transports. -+.TP -+\f4\-N\f1 -+Use the newstyle of rpcgen. This allows procedures to have multiple arguments. -+It also uses the style of parameter passing that closely resembles C. So, when -+passing an argument to a remote procedure you do not have to pass a pointer to -+the argument but the argument itself. This behaviour is different from the oldstyle -+of rpcgen generated code. The newstyle is not the default case because of -+backward compatibility. -+.TP -+\f4\-o \f2outfile\f1 -+Specify the name of the output file. -+If none is specified, -+standard output is used -+(\f4\-c\f1, -+\f4\-h\f1, -+\f4\-l\f1, -+\f4\-m\f1, -+\f4\-n\f1, -+\f4\-s\f1, -+\f4\-s\Sc, -+\f4\-s\Ss -+and -+\f4\-t\f1 -+modes only). -+.TP -+\f4\-s \f2nettype\f1 -+Compile into server-side stubs for all the -+transports belonging to the class -+\f2nettype\f1. -+The supported classes are -+\f4netpath\f1, -+\f4visible\f1, -+\f4circuit_n\f1, -+\f4circuit_v\f1, -+\f4datagram_n\f1, -+\f4datagram_v\f1, -+\f4tcp\f1, -+and -+\f4udp\f1 -+[see \f4rpc\fP(3N) -+for the meanings associated with these classes]. -+This option may be specified more than once. -+Note: -+the transports are chosen at run time and not at compile time. -+.TP -+\f4\-Sc\f1 -+Generate sample code to show the use of remote procedure and how to bind -+to the server before calling the client side stubs generated by rpcgen. -+.TP -+\f4\-Ss\f1 -+Generate skeleton code for the remote procedures on the server side. You would need -+to fill in the actual code for the remote procedures. -+.TP -+\f4\-t\f1 -+Compile into RPC dispatch table. -+.TP -+\f4\-T\f1 -+Generate the code to support RPC dispatch tables. -+.P -+The options -+\f4\-c\f1, -+\f4\-h\f1, -+\f4\-l\f1, -+\f4\-m\f1, -+\f4\-s\f1 -+and -+\f4\-t\f1 -+are used exclusively to generate a particular type of file, -+while the options -+\f4\-D\f1 -+and -+\f4\-T\f1 -+are global and can be used with the other options. -+.br -+.ne 5 -+.SH NOTES -+The RPC Language does not support nesting of structures. -+As a work-around, -+structures can be declared at the top-level, -+and their name used inside other structures in -+order to achieve the same effect. -+.P -+Name clashes can occur when using program definitions, -+since the apparent scoping does not really apply. -+Most of these can be avoided by giving -+unique names for programs, -+versions, -+procedures and types. -+.P -+The server code generated with -+\f4\-n\f1 -+option refers to the transport indicated by -+\f2netid\f1 -+and hence is very site specific. -+.SH EXAMPLE -+The following example: -+.IP -+.ft 4 -+$ rpcgen \-T prot.x -+.ft 1 -+.P -+generates the five files: -+\f4prot.h\f1, -+\f4prot_clnt.c\f1, -+\f4prot_svc.c\f1, -+\f4prot_xdr.c\f1 -+and -+\f4prot_tbl.i\f1. -+.P -+The following example sends the C data-definitions (header file) -+to the standard output. -+.IP -+.ft 4 -+$ rpcgen \-h prot.x -+.ft 1 -+.P -+To send the test version of the -+\f4-DTEST\f1, -+server side stubs for -+all the transport belonging to the class -+\f4datagram_n\f1 -+to standard output, use: -+.IP -+.ft 4 -+$ rpcgen \-s datagram_n \-DTEST prot.x -+.ft 1 -+.P -+To create the server side stubs for the transport indicated -+by -+\f2netid\f1 -+\f4tcp\f1, -+use: -+.IP -+.ft 4 -+$ rpcgen \-n tcp \-o prot_svc.c prot.x -+.ft 1 -+.SH "SEE ALSO" -+\f4cc\fP(1). --- man-pages-extra.orig/man3/rquota.3 1970-01-01 01:00:00.000000000 +0100 +++ man-pages-extra/man3/rquota.3 2001-03-23 13:03:27.000000000 +0100 @@ -0,0 +1,34 @@ -- 2.43.0