neulab/tldr huggingface dataset:
-write Enable writing into executable and core files.
-exec=file -e file Use file file as the executable file to execute when appropriate, and for examining pure data in conjunction with a core dump.
-se=file Read symbol table from file file and use it as the executable file.
-core=file -c file Use file file as a core dump to examine.
-command=file -x file Execute GDB commands from file file.
-ex command Execute given GDB command.
-directory=directory -d directory Add directory to the path to search for source files.
-nh Do not execute commands from ~/.config/gdb/gdbinit, ~/.gdbinit, ~/.config/gdb/gdbearlyinit, or ~/.gdbearlyinit
-nx -n  Do not execute commands from any .gdbinit or .gdbearlyinit initialization files.
-quiet -q  "Quiet".  Do not print the introductory and copyright messages. These messages are also suppressed in batch mode.
-batch Run in batch mode.  Exit with status 0 after processing all the command files specified with -x (and .gdbinit, if not inhibited). Exit with nonzero status if an error occurs in executing the GDB commands in the command files.
Batch mode may be useful for running GDB as a filter, for example to download and run a program on another computer; in order to make this more useful, the message
(which is ordinarily issued whenever a program running under GDB control terminates) is not issued when running in batch mode.
-cd=directory Run GDB using directory as its working directory, instead of the current directory.
-fullname -f  Emacs sets this option when it runs GDB as a subprocess.  It tells GDB to output the full file name and line number in a standard, recognizable fashion each time a stack frame is displayed (which includes each time the program stops).  This recognizable format looks like two \032 characters, followed by the file name, line number and character position separated by colons, and a newline. The Emacs-to-GDB interface program uses the two \032 characters as a signal to display the source code for the frame.
-b bps Set the line speed (baud rate or bits per second) of any serial interface used by GDB for remote debugging.
-tty=device Run using device for your program's standard input and output.
The full documentation for GDB is maintained as a Texinfo manual.  If the "info" and "gdb" programs and GDB's Texinfo documentation are properly installed at your site, the command
info gdb
Using GDB: A Guide to the GNU Source-Level Debugger, Richard M. Stallman and Roland H. Pesch, July 1991.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being "Free Software" and "Free Software Needs Free Documentation", with the Front-Cover Texts being "A GNU Manual," and with the Back-Cover Texts as in (a) below.
(a) The FSF's Back-Cover Text is: "You are free to copy and modify this GNU Manual.  Buying copies from GNU Press supports the FSF in developing GNU and promoting software freedom."
CHRT(1)                           User Commands                          CHRT(1)
chrt - manipulate the real-time attributes of a process
chrt [options] priority command argument ...
chrt [options] -p [priority] PID
chrt sets or retrieves the real-time scheduling attributes of an existing PID, or runs command with the given attributes.
-o, --other Set scheduling policy to SCHED_OTHER (time-sharing scheduling). This is the default Linux scheduling policy.
-f, --fifo Set scheduling policy to SCHED_FIFO (first in-first out).
-r, --rr Set scheduling policy to SCHED_RR (round-robin scheduling). When no policy is defined, the SCHED_RR is used as the default.
-b, --batch Set scheduling policy to SCHED_BATCH (scheduling batch processes). Linux-specific, supported since 2.6.16. The priority argument has to be set to zero.
-i, --idle Set scheduling policy to SCHED_IDLE (scheduling very low priority jobs). Linux-specific, supported since 2.6.23. The priority argument has to be set to zero.
-d, --deadline Set scheduling policy to SCHED_DEADLINE (sporadic task model deadline scheduling). Linux-specific, supported since 3.14. The priority argument has to be set to zero. See also --sched-runtime, --sched-deadline and --sched-period. The relation between the options required by the kernel is runtime ⇐ deadline ⇐ period. chrt copies period to deadline if --sched-deadline is not specified and deadline to runtime if --sched-runtime is not specified. It means that at least --sched-period has to be specified. See sched(7) for more details.
-T, --sched-runtime nanoseconds Specifies runtime parameter for SCHED_DEADLINE policy (Linux-specific).
-P, --sched-period nanoseconds Specifies period parameter for SCHED_DEADLINE policy (Linux-specific).
-D, --sched-deadline nanoseconds Specifies deadline parameter for SCHED_DEADLINE policy (Linux-specific).
-R, --reset-on-fork Use SCHED_RESET_ON_FORK or SCHED_FLAG_RESET_ON_FORK flag. Linux-specific, supported since 2.6.31.
Each thread has a reset-on-fork scheduling flag. When this flag is set, children created by fork(2) do not inherit privileged scheduling policies. After the reset-on-fork flag has been enabled, it can be reset only if the thread has the CAP_SYS_NICE capability. This flag is disabled in child processes created by fork(2).
More precisely, if the reset-on-fork flag is set, the following rules apply for subsequently created children:
•   If the calling thread has a scheduling policy of SCHED_FIFO or SCHED_RR, the policy is reset to SCHED_OTHER in child processes.
•   If the calling process has a negative nice value, the nice value is reset to zero in child processes.
-a, --all-tasks Set or retrieve the scheduling attributes of all the tasks (threads) for a given PID.
-m, --max Show minimum and maximum valid priorities, then exit.
-v, --verbose Show status information.
The default behavior is to run a new command: chrt priority command [arguments]
You can also retrieve the real-time attributes of an existing task: chrt -p PID
Or set them: chrt -r -p priority PID
A user must possess CAP_SYS_NICE to change the scheduling attributes of a process. Any user can retrieve the scheduling information.
Only SCHED_FIFO, SCHED_OTHER and SCHED_RR are part of POSIX 1003.1b Process Scheduling. The other scheduling attributes may be ignored on some systems.
Linux' default scheduling policy is SCHED_OTHER.
Robert Love <rml@tech9.net>, Karel Zak <kzak@redhat.com>
nice(1), renice(1), taskset(1), sched(7)
See sched_setscheduler(2) for a description of the Linux scheduling scheme.
The chrt command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
C99(1POSIX)                 POSIX Programmer's Manual                C99(1POSIX)
c99 — compile standard C programs
c99 [options...] pathname [[pathname] [−I directory] [−L directory] [−l library]]...
The c99 utility is an interface to the standard C compilation system; it shall accept source code conforming to the ISO C standard. The system conceptually consists of a compiler and link editor. The input files referenced by pathname operands and −l option-arguments shall be compiled and linked to produce an executable file. (It is unspecified whether the linking occurs entirely within the operation of c99; some implementations may produce objects that are not fully resolved until the file is executed.)
If the −c option is specified, for all pathname operands of the form file.c, the files:
$(basename pathname .c).o
shall be created as the result of successful compilation. If the −c option is not specified, it is unspecified whether such .o files are created or deleted for the file.c operands.
If there are no options that prevent link editing (such as −c or −E), and all input files compile and link without error, the resulting executable file shall be written according to the −o outfile option (if present) or to the file a.out.
The executable file shall be created as specified in Section 1.1.1.4, File Read, Write, and Creation, except that the file permission bits shall be set to: S_IRWXO | S_IRWXG | S_IRWXU
and the bits specified by the umask of the process shall be cleared.
The c99 utility shall conform to the Base Definitions volume of POSIX.1‐2008, Section 12.2, Utility Syntax Guidelines, except that:
*  Options can be interspersed with operands.
*  The order of specifying the −L and −l options, and the order of specifying −l options with respect to pathname operands is significant.
*  Conforming applications shall specify each option separately; that is, grouping option letters (for example, −cO) need not be recognized by all implementations.
−c        Suppress the link-edit phase of the compilation, and do not remove any object files that are produced.
−D name[=value] Define name as if by a C-language #define directive. If no =value is given, a value of 1 shall be used. The −D option has lower precedence than the −U option. That is, if name is used in both a −U and a −D option, name shall be undefined regardless of the order of the options. Additional implementation-defined names may be provided by the compiler. Implementations shall support at least 2048 bytes of −D definitions and 256 names.
−E        Copy C-language source files to standard output, expanding all preprocessor directives; no compilation shall be performed. If any operand is not a text file, the effects are unspecified.
−g        Produce symbolic information in the object or executable files; the nature of this information is unspecified, and may be modified by implementation-defined interactions with other options.
−I directory Change the algorithm for searching for headers whose names are not absolute pathnames to look in the directory named by the directory pathname before looking in the usual places. Thus, headers whose names are enclosed in double-quotes ("") shall be searched for first in the directory of the file with the #include line, then in directories named in −I options, and last in the usual places. For headers whose names are enclosed in angle brackets ("<>"), the header shall be searched for only in directories named in −I options and then in the usual places. Directories named in −I options shall be searched in the order specified. If the −I option is used to specify a directory that is one of the usual places searched by default, the results are unspecified. Implementations shall support at least ten instances of this option in a single c99 command invocation.
−L directory Change the algorithm of searching for the libraries named in the −l objects to look in the directory named by the directory pathname before looking in the usual places. Directories named in −L options shall be searched in the order specified. If the −L option is used to specify a directory that is one of the usual places searched by default, the results are unspecified. Implementations shall support at least ten instances of this option in a single c99 command invocation. If a directory specified by a −L option contains files with names starting with any of the strings "libc.", "libl.", "libpthread.", "libm.", "librt.", "libtrace.", "libxnet.", or "liby.", the results are unspecified.
−l library Search the library named liblibrary.a.  A library shall be searched when its name is encountered, so the placement of a −l option is significant. Several standard libraries can be specified in this manner, as described in the EXTENDED DESCRIPTION section. Implementations may recognize implementation-defined suffixes other than .a as denoting libraries.
−O optlevel Specify the level of code optimization. If the optlevel option- argument is the digit '0', all special code optimizations shall be disabled. If it is the digit '1', the nature of the optimization is unspecified. If the −O option is omitted, the nature of the system's default optimization is unspecified. It is unspecified whether code generated in the presence of the −O 0 option is the same as that generated when −O is omitted. Other optlevel values may be supported.
−o outfile Use the pathname outfile, instead of the default a.out, for the executable file produced. If the −o option is present with −c or −E, the result is unspecified.
−s        Produce object or executable files, or both, from which symbolic and other information not required for proper execution using the exec family defined in the System Interfaces volume of POSIX.1‐2008 has been removed (stripped). If both −g and −s options are present, the action taken is unspecified.
−U name   Remove any initial definition of name.
Multiple instances of the −D, −I, −L, −l, and −U options can be specified.
The application shall ensure that at least one pathname operand is specified. The following forms for pathname operands shall be supported:
file.c    A C-language source file to be compiled and optionally linked. The application shall ensure that the operand is of this form if the −c option is used.
file.a    A library of object files typically produced by the ar utility, and passed directly to the link editor. Implementations may recognize implementation-defined suffixes other than .a as denoting object file libraries.
file.o    An object file produced by c99 −c and passed directly to the link editor. Implementations may recognize implementation- defined suffixes other than .o as denoting object files.
The processing of other files is implementation-defined.
Each input file shall be one of the following: a text file containing a C-language source program, an object file in the format produced by c99 −c, or a library of object files, in the format produced by archiving zero or more object files, using ar.  Implementations may supply additional utilities that produce files in these formats. Additional input file formats are implementation-defined.
The following environment variables shall affect the execution of c99:
TMPDIR    Provide a pathname that should override the default directory for temporary files, if any.  On XSI-conforming systems, provide a pathname that shall override the default directory for temporary files, if any.
If more than one pathname operand ending in .c (or possibly other unspecified suffixes) is given, for each such file:
"%s:\n", <pathname>
may be written. These messages, if written, shall precede the processing of each input file; they shall not be written to the standard output if they are written to the standard error, as described in the STDERR section.
If the −E option is specified, the standard output shall be a text file that represents the results of the preprocessing stage of the language; it may contain extra information appropriate for subsequent compilation passes.
The standard error shall be used only for diagnostic messages.  If more than one pathname operand ending in .c (or possibly other unspecified suffixes) is given, for each such file:
may be written to allow identification of the diagnostic and warning messages with the appropriate input file. These messages, if written, shall precede the processing of each input file; they shall not be written to the standard error if they are written to the standard output, as described in the STDOUT section.
This utility may produce warning messages about certain conditions that do not warrant returning an error (non-zero) exit value.
Object files or executable files or both are produced in unspecified formats. If the pathname of an object file or executable file to be created by c99 resolves to an existing directory entry for a file that is not a regular file, it is unspecified whether c99 shall attempt to create the file or shall issue a diagnostic and exit with a non-zero exit status.
Standard Libraries The c99 utility shall recognize the following −l options for standard libraries:
−l c      This option shall make available all interfaces referenced in the System Interfaces volume of POSIX.1‐2008, with the possible exception of those interfaces listed as residing in <aio.h>, <arpa/inet.h>, <complex.h>, <fenv.h>, <math.h>, <mqueue.h>, <netdb.h>, <net/if.h>, <netinet/in.h>, <pthread.h>, <sched.h>, <semaphore.h>, <spawn.h>, <sys/socket.h>, pthread_kill(), and pthread_sigmask() in <signal.h>, <trace.h>, interfaces marked as optional in <sys/mman.h>, interfaces marked as ADV (Advisory Information) in <fcntl.h>, and interfaces beginning with the prefix clock_ or time_ in <time.h>.  This option shall not be required to be present to cause a search of this library.
−l l      This option shall make available all interfaces required by the C-language output of lex that are not made available through the −l c option.
−l pthread This option shall make available all interfaces referenced in <pthread.h> and pthread_kill() and pthread_sigmask() referenced in <signal.h>.  An implementation may search this library in the absence of this option.
−l m      This option shall make available all interfaces referenced in <math.h>, <complex.h>, and <fenv.h>.  An implementation may search this library in the absence of this option.
−l rt     This option shall make available all interfaces referenced in <aio.h>, <mqueue.h>, <sched.h>, <semaphore.h>, and <spawn.h>, interfaces marked as optional in <sys/mman.h>, interfaces marked as ADV (Advisory Information) in <fcntl.h>, and interfaces beginning with the prefix clock_ and time_ in <time.h>.  An implementation may search this library in the absence of this option.
−l trace  This option shall make available all interfaces referenced in <trace.h>.  An implementation may search this library in the absence of this option.
−l xnet   This option shall make available all interfaces referenced in <arpa/inet.h>, <netdb.h>, <net/if.h>, <netinet/in.h>, and <sys/socket.h>.  An implementation may search this library in the absence of this option.
−l y      This option shall make available all interfaces required by the C-language output of yacc that are not made available through the −l c option.
In the absence of options that inhibit invocation of the link editor, such as −c or −E, the c99 utility shall cause the equivalent of a −l c option to be passed to the link editor after the last pathname operand or −l option, causing it to be searched after all other object files and libraries are loaded.
It is unspecified whether the libraries libc.a, libl.a, libm.a, libpthread.a, librt.a, libtrace.a, libxnet.a, or liby.a exist as regular files. The implementation may accept as −l option-arguments names of objects that do not exist as regular files.
External Symbols The C compiler and link editor shall support the significance of external symbols up to a length of at least 31 bytes; the action taken upon encountering symbols exceeding the implementation-defined maximum symbol length is unspecified.
The compiler and link editor shall support a minimum of 511 external symbols per source or object file, and a minimum of 4095 external symbols in total. A diagnostic message shall be written to the standard output if the implementation-defined limit is exceeded; other actions are unspecified.
Header Search If a file with the same name as one of the standard headers defined in the Base Definitions volume of POSIX.1‐2008, Chapter 13, Headers, not provided as part of the implementation, is placed in any of the usual places that are searched by default for headers, the results are unspecified.
Programming Environments All implementations shall support one of the following programming environments as a default. Implementations may support more than one of the following programming environments. Applications can use sysconf() or getconf to determine which programming environments are supported.
Table 4-4: Programming Environments: Type Sizes
┌────────────────────────┬─────────┬─────────┬─────────┬─────────┐ │Programming Environment │ Bits in │ Bits in │ Bits in │ Bits in │ │     getconf Name       │   int   │  long   │ pointer │  off_t  │ ├────────────────────────┼─────────┼─────────┼─────────┼─────────┤ │_POSIX_V7_ILP32_OFF32   │    32   │    32   │    32   │    32   │ │_POSIX_V7_ILP32_OFFBIG  │    32   │    32   │    32   │   ≥64   │ │_POSIX_V7_LP64_OFF64    │    32   │    64   │    64   │    64   │ │_POSIX_V7_LPBIG_OFFBIG  │   ≥32   │   ≥64   │   ≥64   │   ≥64   │ └────────────────────────┴─────────┴─────────┴─────────┴─────────┘ All implementations shall support one or more environments where the widths of the following types are no greater than the width of type long:
blksize_t   ptrdiff_t     tcflag_t cc_t        size_t        wchar_t mode_t      speed_t       wint_t nfds_t      ssize_t pid_t       suseconds_t
The executable files created when these environments are selected shall be in a proper format for execution by the exec family of functions. Each environment may be one of the ones in Table 4-4, Programming Environments: Type Sizes, or it may be another environment. The names for the environments that meet this requirement shall be output by a getconf command using the POSIX_V7_WIDTH_RESTRICTED_ENVS argument, as a <newline>-separated list of names suitable for use with the getconf −v option. If more than one environment meets the requirement, the names of all such environments shall be output on separate lines. Any of these names can then be used in a subsequent getconf command to obtain the flags specific to that environment with the following suffixes added as appropriate:
_CFLAGS   To get the C compiler flags.
_LDFLAGS  To get the linker/loader flags.
_LIBS     To get the libraries.
This requirement may be removed in a future version.
When this utility processes a file containing a function called main(), it shall be defined with a return type equivalent to int.  Using return from the initial call to main() shall be equivalent (other than with respect to language scope issues) to calling exit() with the returned value. Reaching the end of the initial call to main() shall be equivalent to calling exit(0).  The implementation shall not declare a prototype for this function.
Implementations provide configuration strings for C compiler flags, linker/loader flags, and libraries for each supported environment.  When an application needs to use a specific programming environment rather than the implementation default programming environment while compiling, the application shall first verify that the implementation supports the desired environment. If the desired programming environment is supported, the application shall then invoke c99 with the appropriate C compiler flags as the first options for the compile, the appropriate linker/loader flags after any other options except −l but before any operands or −l options, and the appropriate libraries at the end of the operands and −l options.
Conforming applications shall not attempt to link together object files compiled for different programming models. Applications shall also be aware that binary data placed in shared memory or in files might not be recognized by applications built for other programming models.
Table 4-5: Programming Environments: c99 Arguments
┌────────────────────────┬─────────────────────┬───────────────────────────────┐ │Programming Environment │                     │         c99 Arguments         │ │     getconf Name       │         Use         │         getconf Name          │ ├────────────────────────┼─────────────────────┼───────────────────────────────┤ │_POSIX_V7_ILP32_OFF32   │ C Compiler Flags    │ POSIX_V7_ILP32_OFF32_CFLAGS   │ │                        │ Linker/Loader Flags │ POSIX_V7_ILP32_OFF32_LDFLAGS  │ │                        │ Libraries           │ POSIX_V7_ILP32_OFF32_LIBS     │ ├────────────────────────┼─────────────────────┼───────────────────────────────┤ │_POSIX_V7_ILP32_OFFBIG  │ C Compiler Flags    │ POSIX_V7_ILP32_OFFBIG_CFLAGS  │ │                        │ Linker/Loader Flags │ POSIX_V7_ILP32_OFFBIG_LDFLAGS │ │                        │ Libraries           │ POSIX_V7_ILP32_OFFBIG_LIBS    │ ├────────────────────────┼─────────────────────┼───────────────────────────────┤ │_POSIX_V7_LP64_OFF64    │ C Compiler Flags    │ POSIX_V7_LP64_OFF64_CFLAGS    │ │                        │ Linker/Loader Flags │ POSIX_V7_LP64_OFF64_LDFLAGS   │ │                        │ Libraries           │ POSIX_V7_LP64_OFF64_LIBS      │ ├────────────────────────┼─────────────────────┼───────────────────────────────┤ │_POSIX_V7_LPBIG_OFFBIG  │ C Compiler Flags    │ POSIX_V7_LPBIG_OFFBIG_CFLAGS  │ │                        │ Linker/Loader Flags │ POSIX_V7_LPBIG_OFFBIG_LDFLAGS │ │                        │ Libraries           │ POSIX_V7_LPBIG_OFFBIG_LIBS    │ └────────────────────────┴─────────────────────┴───────────────────────────────┘ In addition to the type size programming environments above, all implementations also support a multi-threaded programming environment that is orthogonal to all of the programming environments listed above. The getconf utility can be used to get flags for the threaded programming environment, as indicated in Table 4-6, Threaded Programming Environment: c99 Arguments.
Table 4-6: Threaded Programming Environment: c99 Arguments
┌────────────────────────┬─────────────────────┬──────────────────────────┐ │Programming Environment │                     │      c99 Arguments       │ │     getconf Name       │         Use         │       getconf Name       │ ├────────────────────────┼─────────────────────┼──────────────────────────┤ │_POSIX_THREADS          │ C Compiler Flags    │ POSIX_V7_THREADS_CFLAGS  │ │                        │ Linker/Loader Flags │ POSIX_V7_THREADS_LDFLAGS │ └────────────────────────┴─────────────────────┴──────────────────────────┘ These programming environment flags may be used in conjunction with any of the type size programming environments supported by the implementation.
0    Successful compilation or link edit.
When c99 encounters a compilation error that causes an object file not to be created, it shall write a diagnostic to standard error and continue to compile other source code operands, but it shall not perform the link phase and return a non-zero exit status. If the link edit is unsuccessful, a diagnostic message shall be written to standard error and c99 exits with a non-zero status. A conforming application shall rely on the exit status of c99, rather than on the existence or mode of the executable file.
Since the c99 utility usually creates files in the current directory during the compilation process, it is typically necessary to run the c99 utility in a directory in which a file can be created.
On systems providing POSIX Conformance (see the Base Definitions volume of POSIX.1‐2008, Chapter 2, Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99.
Some historical implementations have created .o files when −c is not specified and more than one source file is given. Since this area is left unspecified, the application cannot rely on .o files being created, but it also must be prepared for any related .o files that already exist being deleted at the completion of the link edit.
There is the possible implication that if a user supplies versions of the standard functions (before they would be encountered by an implicit −l c or explicit −l m), that those versions would be used in place of the standard versions.  There are various reasons this might not be true (functions defined as macros, manipulations for clean name space, and so on), so the existence of files named in the same manner as the standard libraries within the −L directories is explicitly stated to produce unspecified behavior.
All of the functions specified in the System Interfaces volume of POSIX.1‐2008 may be made visible by implementations when the Standard C Library is searched. Conforming applications must explicitly request searching the other standard libraries when functions made visible by those libraries are used.
In the ISO C standard the mapping from physical source characters to the C source character set is implementation-defined. Implementations may strip white-space characters before the terminating <newline> of a (physical) line as part of this mapping and, as a consequence of this, one or more white-space characters (and no other characters) between a <backslash> character and the <newline> character that terminates the line produces implementation-defined results. Portable applications should not use such constructs.
Some c99 compilers not conforming to POSIX.1‐2008 do not support trigraphs by default.
1. The following usage example compiles foo.c and creates the executable file foo:
c99 −o foo foo.c
The following usage example compiles foo.c and creates the object file foo.o:
c99 −c foo.c
The following usage example compiles foo.c and creates the executable file a.out:
c99 foo.c
The following usage example compiles foo.c, links it with bar.o, and creates the executable file a.out.  It may also create and leave foo.o:
c99 foo.c bar.o
2. The following example shows how an application using threads interfaces can test for support of and use a programming environment supporting 32-bit int, long, and pointer types and an off_t type using at least 64 bits:
offbig_env=$(getconf _POSIX_V7_ILP32_OFFBIG) if [ $offbig_env != "-1" ] && [ $offbig_env != "undefined" ] then c99 $(getconf POSIX_V7_ILP32_OFFBIG_CFLAGS) \ $(getconf POSIX_V7_THREADS_CFLAGS) -D_XOPEN_SOURCE=700 \ $(getconf POSIX_V7_ILP32_OFFBIG_LDFLAGS) \ $(getconf POSIX_V7_THREADS_LDFLAGS) foo.c -o foo \ $(getconf POSIX_V7_ILP32_OFFBIG_LIBS) \ -l pthread else echo ILP32_OFFBIG programming environment not supported exit 1 fi
3. The following examples clarify the use and interactions of −L and −l options.
Consider the case in which module a.c calls function f() in library libQ.a, and module b.c calls function g() in library libp.a.  Assume that both libraries reside in /a/b/c.  The command line to compile and link in the desired way is:
c99 −L /a/b/c main.o a.c −l Q b.c −l p
In this case the −L option need only precede the first −l option, since both libQ.a and libp.a reside in the same directory.
Multiple −L options can be used when library name collisions occur. Building on the previous example, suppose that the user wants to use a new libp.a, in /a/a/a, but still wants f() from /a/b/c/libQ.a:
c99 −L /a/a/a −L /a/b/c main.o a.c −l Q b.c −l p
In this example, the linker searches the −L options in the order specified, and finds /a/a/a/libp.a before /a/b/c/libp.a when resolving references for b.c.  The order of the −l options is still important, however.
4. The following example shows how an application can use a programming environment where the widths of the following types: blksize_t, cc_t, mode_t, nfds_t, pid_t, ptrdiff_t, size_t, speed_t, ssize_t, suseconds_t, tcflag_t, wchar_t, wint_t
are no greater than the width of type long:
# First choose one of the listed environments ...
# ... if there are no additional constraints, the first one will do: CENV=$(getconf POSIX_V7_WIDTH_RESTRICTED_ENVS | head -n l)
# ... or, if an environment that supports large files is preferred, # look for names that contain "OFF64" or "OFFBIG". (This chooses # the last one in the list if none match.) for CENV in $(getconf POSIX_V7_WIDTH_RESTRICTED_ENVS) do case $CENV in *OFF64*|*OFFBIG*) break ;; esac done
# The chosen environment name can now be used like this:
c99 $(getconf ${CENV}_CFLAGS) -D _POSIX_C_SOURCE=200809L \ $(getconf ${CENV}_LDFLAGS) foo.c -o foo \ $(getconf ${CENV}_LIBS)
The c99 utility is based on the c89 utility originally introduced in the ISO POSIX‐2:1993 standard.
Some of the changes from c89 include the ability to intersperse options and operands (which many c89 implementations allowed despite it not being specified), the description of −l as an option instead of an operand, and the modification to the contents of the Standard Libraries section to account for new headers and options; for example, <spawn.h> added to the description of −l rt, and −l trace added for the Tracing option.
POSIX.1‐2008 specifies that the c99 utility must be able to use regular files for *.o files and for a.out files. Implementations are free to overwrite existing files of other types when attempting to create object files and executable files, but are not required to do so. If something other than a regular file is specified and using it fails for any reason, c99 is required to issue a diagnostic message and exit with a non-zero exit status. But for some file types, the problem may not be noticed for a long time. For example, if a FIFO named a.out exists in the current directory, c99 may attempt to open a.out and will hang in the open() call until another process opens the FIFO for reading. Then c99 may write most of the a.out to the FIFO and fail when it tries to seek back close to the start of the file to insert a timestamp (FIFOs are not seekable files). The c99 utility is also allowed to issue a diagnostic immediately if it encounters an a.out or *.o file that is not a regular file. For portable use, applications should ensure that any a.out, −o option-argument, or *.o files corresponding to any *.c files do not conflict with names already in use that are not regular files or symbolic links that point to regular files.
On many systems, multi-threaded applications run in a programming environment that is distinct from that used by single-threaded applications. This multi-threaded programming environment (in addition to needing to specify −l pthread at link time) may require additional flags to be set when headers are processed at compile time (−D_REENTRANT being common). This programming environment is orthogonal to the type size programming environments discussed above and listed in Table 4-4, Programming Environments: Type Sizes.  This version of the standard adds getconf utility calls to provide the C compiler flags and linker/loader flags needed to support multi-threaded applications. Note that on a system where single-threaded applications are a special case of a multi- threaded application, both of these getconf calls may return NULL strings; on other implementations both of these strings may be non-NULL strings.
The C standardization committee invented trigraphs (e.g., "??!" to represent '|') to address character portability problems in development environments based on national variants of the 7-bit ISO/IEC 646:1991 standard character set. However, these environments were already obsolete by the time the first ISO C standard was published, and in practice trigraphs have not been used for their intended purpose, and usually are intended to have their original meaning in K&R C.  For example, in practice a C-language source string like "What??!" is usually intended to end in two <question-mark> characters and an <exclamation-mark>, not in '|'.
Section 1.1.1.4, File Read, Write, and Creation, ar, getconf, make, nm, strip, umask
The Base Definitions volume of POSIX.1‐2008, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines, Chapter 13, Headers
The System Interfaces volume of POSIX.1‐2008, exec, sysconf()
JCAL(1)                    BSD General Commands Manual                   JCAL(1)
jcal — displays a calendar
jcal [-epPVjy13] [[month] year]
jcal displays a simple calendar.  If arguments are not specified, the current month is displayed.  The options are as follows:
-1      Display single month output.  (This is the default.)
-3      Display prev/current/next month output.
-j      Display Julian dates (days one-based, numbered from Farvardin 1).
-p      Display Farsi numbers and names.
-P      Display year based on Pahlavi epoch.
-e      Display english names for weekdays.
-y      Display a calendar for the current year.
-V      Display calendar version.
A single parameter specifies the year (1 - 9999) to be displayed; note the year must be fully specified: “cal 90” will not display a calendar for 1390.  Two parameters denote the month (1 - 12) and year.  If no parameters are specified, the current month's calendar is displayed.
A year starts on Far 1.
True solar year, also known as tropical year, was a still later discovery. One has to take equinox or solstice into account to keep an accurate track of the solar year.  The equinoxes are the two intersections of the sun's apparent annual path with the celestial equator. The sun reaches the vernal equinox on 1st of Farvardin, on or about 21st March, the summer solstice on 1st of Tir, on about 22nd June, the autumnal equinox on 1st Mehr, on or about 23rd September, and the winter solstice on 1st of Dey, on or about 22 December. Because the two planes, the path of the sun and the celestial equator move in opposite directions, the equinoxes and solstices do not occur at the same points every year. This anti-clock movement of the intersection point is called precession. It moves one degree in 72 years, one Zodiac sign of 30 degrees in 2,156 years and one circle in 25,868 years. For further information on calendar, solar or tropical year, precession, and other astronomical data, refer to any good encyclopedia or a publication on astronomy and astrology.  The tropical year, based on the four seasons, is precise. It is 365.24224 solar days (365 days 5 hr 48 min 45.5 sec), and the tropical lunar year is 354.36708 solar days, a difference of 10.87516 solar days.  We need not go far to find a workable calendar. Of all the present calendars, the official Iranian calendar, based on the astronomical system, is the most scientific calendar in use and bears the names of what are known as Zoroastrian months. It rightly has the vernal equinox (on or about 21st March) at the beginning of the spring and the year. The fourth month begins on the summer solstice (on or about 22 June), the seventh month on the autumnal equinox (on or about 23 September), and the ninth month on the winter solstice (on or about 22 December).  In the true seasonal year, the first half contains 186 days and the second half about 179.242 days. This means that the first six months are of 31 days each, the following five months of 30 days each, and the last month of 29 days, but which automatically becomes of 30 days in the so-called "leap" year. The four seasons begin on the first days of the seasonal quarters.  This is exactly what the Iranian calendar follows: The first six months are of 31 days each, the next five months of 30 days each and the last month is of 29 days but of 30 days in the leap year. Reports indicate that the Central Asian republics may follow suit.  Historical evidence that the five Gatha days were added at the end of summer proves that the early "Zoroastrian" calendar had this fact in view.
THE INDO-IRANIAN CALENDAR Evidences from the Avesta and the Vedas show that the Indo-Iranians, like many other people, followed a lunisolar year for their animal husbandry and agricultural purpose.  The names of the six Gaahaanbaars, six parts of the Vedic year and the Achaemenian months, as seen below, show that the calendar was based on various seasonal phases of the year.  The Gathas speak of the paths of the sun and the stars, and speaks about the waxing and waning phases of the moon, a sure sign of an accurate lunisolar year. The language used is astronomical, and it confirms the reports written in ancient Middle Eastern and Mediterranean writings that Zarathushtra was an outstanding astronomer also.  It also confirms the statement in post- Sassanian Iranian astronomy books that Zarathushtra built an observatory in Zabol, Sistan (eastern Iran) and that it was inaugurated on 21st March 1725 BCE, the day King Vishtaspa and his courtiers converted, chose the Good Religion and joined the Zarathushtrian Fellowship.  It also provides us with the clue that the Good Religion was founded by Zarathushtra, exactly twelve years earlier on vernal equinox of 1737 BCE.  The Vispered, dedicated only to the six seasonal festivals, the "Gaahaanbaars", also shows that the early Zarathushtrian calendar was almost the old Indo- Iranian lunisolar calendar with its waxing and waning lunar phases. The month was based on moon's phases, and the year was calculated on the solar basis.  The difference was corrected by an intercalation of eleven days at the end of the year on the Hamaspathmaidhaya Gahanbar of the vernal equinox. This was 0.12484 day or 2.99616 hours shorter. Only a further intercalation of one day after eight years (precisely after 8.010253 years), could keep the seasonal festivals in their proper places. How did the Gathic people correct it, we do not know. We know this much that no complaint has been recorded by them about the festivals drifting away from their relevant agricultural seasons.  Sometime during the later Avestan age, the year was made into a purely solar year of 365 days with twelve months of thirty days and the five "Gatha" days as the intercalary period. Should we believe a 9th century Pahlavi tradition, the correction of five hours and a fraction was made good every four years, or the community had to wait for 40 years to intercalate 10 days or still more for 120 years to add a thirteenth month of 30 days. The usual reference to one month intercalation at the end of 120 years only reminds us of the disorder that prevailed during the last days of the Sassanian Empire and its subsequent fall.
A point about intercalation in a ``leap'' year: The precise time of vernal equinox is determined by the International Meridian, at present Greenwich. The usual way is to count the year of 365 days and 6 hours. Four 6 hours, or one day, is added to bring back the year on the right track. This fourth year is called the ``leap year'' because it leaps one day ahead. But the actual length of the year is 6 hours but 5 hours 48 minutes and 45.5 seconds, a difference of 11 minutes and 14.5 seconds.  This amount to one day in 128 days. It was to correct this that the leap years are those eras which are divisible by 400. Even this makes the Christian or Common year 26 seconds longer than the tropical year.  The Iranian calendar does not have this problem. Its new year begins exactly at the beginning of the equinox. Although the formal Iranian year of the present days has its leap year, it should never worry about it.  All it has to do is to see that if the right times falls after midnight 0 hours 00 minutes and 01 seconds to 0 hours 00 minutes and 00 seconds -- the first day of the year also begins with it. This is because the Avestan day begins with the ``Ushahin Gaah,'' the Dawn Time, which begins from midnight. Yes, the Iranians have been counting their day from midnight for, at least, 3738 years and it is the West that has adopted it very late in our times. The Iranian calendar DOES NOT need a leap year at all. It is automatically within the right time. I hope that one day the authorities concerned would realize this FACT and amend the calendar by eliminating the so-called leap year.
Each of the twelve Avestan months and thirty days were named after a deity, some of them old Aryan gods and goddesses discarded by Zarathushtra but reintroduced later by authoritative priests, and some of them Gathic principles personified by the same priests into divine entities, all now called yazatas, meaning "venerated, venerable."  "Year" in general was called "yaairi" or "yaari", but the intercalated solar year was known as "saredha", Old Persian of the Achaemenians "tharda", and Pahlavi and modern Persian "saal" (compared Sanskrit "sharad", autumn, year).  This calendar is followed to this day by Iranian Zartoshtis and some Parsis. It is called Fasli, a modern Persian-Arabic word meaning "seasonal" However, majority of Parsis use Shahenshahi, the "Imperial" calendar. The Parsis have not intercalated since 1126 CE.  It now begins in the last week of August 21st, full seven months plus one day earlier. The Iranian Zoroastrians, who follow the Qadimi Calendar, have abandoned intercalation since 1006 CE and the 365-day year has now forwarded their new year day by eight months. As seen, the two calendars are neither precisely "Gathic" nor astronomically scientific. So is the present Zoroastrian era of 1370 followed by the Shahenshahis, Qadimis and Parsi Faslis. It is based on the ascension of the last Sassanian king Yazdegerd III (632-642 CE + 10 years of wandering until his murder by Khosrow the miller) and has no religious significance at all. Fortunately, with the exception of a minute number, mostly residing in India, all Iranian Zoroastrians have given up the Qadimi calendar in favor of the Fasli one, and they reckon the Zarathushtrian Religious Era as the beginning. At present there is a move to unify all Zoroastrians, at least in North America and Europe, to adopt the Fasli calendar.
The Gaahaanbaars: The agricultural people were in tune with nature in their day-to-day life. They fully knew the solar and lunar movements and the changes in the seasons. They had timed their activities to suit the climate in which they lived. This timetable was kept in step with saredha, the tropical solar year of 365 days, 5 hr, 48 min, and 45.5 sec, but differed a little on certain points.  Their activities were scheduled to correspond with various phases of their agricultural life on the Iranian Plateau. It was divided into six phases. The end of one phase and the beginning of other were celebrated as a special time of festivity. The six seasonal festivals were: (1) Hamaspathmaidhaya, meaning "vernal equinox," the 1st day of Farvardin, the beginning of spring, on or about 21st March, was to celebrate the end of the old year and the beginning of the new year. It was, according to the Avesta, the time to "properly set" everything and prepare for the new year.  (2) Maidhyoi-zaremaya (Mid-spring), 14th day of Ardibehesht, on or about 4th May, was the time to celebrate the occasion for the cattle having delivered their young and yielded "abundance of milk" and also for appraising the crops sown in late winter or early spring.  (3) Maidhyoi-shema (Midsummer), 12th day of Tir, on or about 3rd July, was the beginning of the harvesting season.  (4) Paitish-hahya (Grain-reaping), 25th day of Shahrivar, on or about 16th September, marked the end of harvesting.  (5) Ayaathrema (no-travel), 24th day of Mehr, on or about 16th October, was to enjoy the end of trade caravans and the time to mate cattle before the winter set in.  (6) Maidhyaairya (Midyear), 15th day of Dey, on or about 4th January, heralded the passing of the winter peak and for making preparations to meet the spring with agricultural activity.
Only the first two festivals coincided with the solar seasonal changes. The others were purposely put off to meet the living conditions. They were not calendarically or traditionally bound but were very practical people, a point to note.  Most probably the festivals were celebrated with sacrifices to gods and goddesses and by indulging in a joyous festivity.  Gahanbars and Zarathushtrians: Asho Zarathushtra, born in an agricultural environment, preached and spread his Good Religion among people engaged in crop cultivation and animal husbandry. His dynamic message introduced a completely new order in spiritual, or better, as he put it, mental sphere and purged out all evil and superstitious thoughts, misleading words, harmful deeds, and superficial, superfluous rituals, but helped to strengthen and promote all the then-existing constructive activities of a good living.  And the Gahanbars were one of the constructively enjoyable festivals.
Chanting and Feasting: Avestan evidences, particularly the book of Vispered, show that the early Zarathushtrians turned the Gahanbar into an occasion to fit into their new pattern of life. Each festival was traditionally celebrated for one and later for five days. They were devoted to reciting, chanting, explaining, understanding, and holding questions-and-answers on each of the five Gathas of Asho Zarathushtra. The festival was rounded up with a feast prepared by collective participation and efforts, and merrymaking.  A piece in the Avesta directs that all participants should bring whatever they can afford; dairy products, meat, vegetables, legumes, grain, other food ingredients, and firewood. If one was not in a position to contribute in kind, one might put his or her labor in preparing the food in a common pot, or just join the prayers. The food, with a large variety of ingredients, was a tasty stew, resembling today's more sophisticated Iranian "aash" or the Parsi spiced "dhansaak", both relished on the occasion. Merrymaking was the folk music and dances still observed among Iranian tribes all over the Iranian Plateau and beyond.  The Zarathushtrian Assembly celebrates the Gahanbars with a relevant Gahanbar prayer, Gatha recital and explanation, a brief talk on an interesting subject, potluck lunch, friendly conversation, and music and dance.