{
    "mode": "info",
    "parameter": "Common options",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/info/Common+options/json",
    "generated": "2026-08-21T05:19:57Z",
    "sections": {
        "File: coreutils.info,  Node: Common options,  Next: Output of entire files,  Prev: Introduction,  Up: Top": {
            "content": "",
            "subsections": []
        },
        "2 Common options": {
            "content": "",
            "subsections": []
        },
        "Certain options are available in all of these programs.  Rather than": {
            "content": "writing identical descriptions for each of the programs, they are\ndescribed here.  (In fact, every GNU program accepts (or should accept)\nthese options.)\n\nNormally options and operands can appear in any order, and programs\nact as if all the options appear before any operands.  For example,\n'sort -r passwd -t :' acts like 'sort -r -t : passwd', since ':' is an\noption-argument of '-t'.  However, if the 'POSIXLYCORRECT' environment\nvariable is set, options must appear before operands, unless otherwise\nspecified for a particular command.\n\nA few programs can usefully have trailing operands with leading '-'.",
            "subsections": []
        },
        "With such a program, options must precede operands even if": {
            "content": "'POSIXLYCORRECT' is not set, and this fact is noted in the program\ndescription.  For example, the 'env' command's options must appear\nbefore its operands, since in some cases the operands specify a command\nthat itself contains options.\n\nMost programs that accept long options recognize unambiguous\nabbreviations of those options.  For example, 'rmdir\n--ignore-fail-on-non-empty' can be invoked as 'rmdir --ignore-fail' or\neven 'rmdir --i'.  Ambiguous options, such as 'ls --h', are identified\nas such.\n\nSome of these programs recognize the '--help' and '--version' options\nonly when one of them is the sole command line argument.  For these\nprograms, abbreviations of the long options are not always recognized.\n\n'--help'\nPrint a usage message listing all available options, then exit\nsuccessfully.\n\n'--version'\nPrint the version number, then exit successfully.\n\n'--'\nDelimit the option list.  Later arguments, if any, are treated as\noperands even if they begin with '-'.  For example, 'sort -- -r'\nreads from the file named '-r'.\n\nA single '-' operand is not really an option, though it looks like\none.  It stands for a file operand, and some tools treat it as standard\ninput, or as standard output if that is clear from the context.  For\nexample, 'sort -' reads from standard input, and is equivalent to plain\n'sort'.  Unless otherwise specified, a '-' can appear as any operand\nthat requires a file name.\n\n* Menu:\n\nItems shared between some programs:\n\n* Backup options::               '-b' '-S'.\n* Block size::                   BLOCKSIZE and '--block-size'.\n* Signal specifications::        Specifying signals with '--signal'.\n* Disambiguating names and IDs:: chgrp, chown, chroot, id: user and group syntax\n* Random sources::               '--random-source'.\n* Target directory::             Specifying a target directory.\n* Trailing slashes::             '--strip-trailing-slashes'.\n* Traversing symlinks::          '-H', '-L', or '-P'.\n* Treating / specially::         '--preserve-root' and the converse.\n* Special built-in utilities::   'break', ':', ...\n\nItems applicable to all programs:\n\n* Exit status::                  Indicating program success or failure.\n* Floating point::               Floating point number representation.\n* Standards conformance::        Conformance to the POSIX standard.\n* Multi-call invocation::        Multi-call program invocation.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Backup options,  Next: Block size,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.1 Backup options",
                    "content": ""
                }
            ]
        },
        "Some GNU programs (at least 'cp', 'install', 'ln', and 'mv') optionally": {
            "content": "make backups of files before writing new versions.  These options\ncontrol the details of these backups.  The options are also briefly\nmentioned in the descriptions of the particular programs.\n\n'-b'\n'--backup[=METHOD]'\nMake a backup of each file that would otherwise be overwritten or\nremoved.  Without this option, the original versions are destroyed.\nUse METHOD to determine the type of backups to make.  When this\noption is used but METHOD is not specified, then the value of the\n'VERSIONCONTROL' environment variable is used.  And if\n'VERSIONCONTROL' is not set, the default backup type is\n'existing'.\n\nNote that the short form of this option, '-b' does not accept any\nargument.  Using '-b' is equivalent to using '--backup=existing'.\n\nThis option corresponds to the Emacs variable 'version-control';\nthe values for METHOD are the same as those used in Emacs.  This\noption also accepts more descriptive names.  The valid METHODs are\n(unique abbreviations are accepted):\n\n'none'\n'off'\nNever make backups.\n\n'numbered'\n't'\nAlways make numbered backups.\n\n'existing'\n'nil'\nMake numbered backups of files that already have them, simple\nbackups of the others.\n\n'simple'\n'never'\nAlways make simple backups.  Please note 'never' is not to be\nconfused with 'none'.\n\n'-S SUFFIX'\n'--suffix=SUFFIX'\nAppend SUFFIX to each backup file made with '-b'.  If this option\nis not specified, the value of the 'SIMPLEBACKUPSUFFIX'\nenvironment variable is used.  And if 'SIMPLEBACKUPSUFFIX' is not\nset, the default is '~', just as in Emacs.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Block size,  Next: Signal specifications,  Prev: Backup options,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.2 Block size",
                    "content": ""
                }
            ]
        },
        "Some GNU programs (at least 'df', 'du', and 'ls') display sizes in": {
            "content": "\"blocks\".  You can adjust the block size and method of display to make\nsizes easier to read.  The block size used for display is independent of\nany file system block size.  Fractional block counts are rounded up to\nthe nearest integer.\n\nThe default block size is chosen by examining the following\nenvironment variables in turn; the first one that is set determines the\nblock size.\n\n'DFBLOCKSIZE'\nThis specifies the default block size for the 'df' command.\nSimilarly, 'DUBLOCKSIZE' specifies the default for 'du' and\n'LSBLOCKSIZE' for 'ls'.\n\n'BLOCKSIZE'\nThis specifies the default block size for all three commands, if\nthe above command-specific environment variables are not set.\n\n'BLOCKSIZE'\nThis specifies the default block size for all values that are\nnormally printed as blocks, if neither 'BLOCKSIZE' nor the above\ncommand-specific environment variables are set.  Unlike the other\nenvironment variables, 'BLOCKSIZE' does not affect values that are\nnormally printed as byte counts, e.g., the file sizes contained in\n'ls -l' output.\n\n'POSIXLYCORRECT'\nIf neither 'COMMANDBLOCKSIZE', nor 'BLOCKSIZE', nor 'BLOCKSIZE'\nis set, but this variable is set, the block size defaults to 512.\n\nIf none of the above environment variables are set, the block size\ncurrently defaults to 1024 bytes in most contexts, but this number may\nchange in the future.  For 'ls' file sizes, the block size defaults to 1\nbyte.\n\nA block size specification can be a positive integer specifying the\nnumber of bytes per block, or it can be 'human-readable' or 'si' to\nselect a human-readable format.  Integers may be followed by suffixes\nthat are upward compatible with the SI prefixes\n(http://www.bipm.org/en/publications/si-brochure/chapter3.html) for\ndecimal multiples and with the ISO/IEC 80000-13 (formerly IEC 60027-2)\nprefixes (https://physics.nist.gov/cuu/Units/binary.html) for binary\nmultiples.\n\nWith human-readable formats, output sizes are followed by a size\nletter such as 'M' for megabytes.  'BLOCKSIZE=human-readable' uses\npowers of 1024; 'M' stands for 1,048,576 bytes.  'BLOCKSIZE=si' is\nsimilar, but uses powers of 1000 and appends 'B'; 'MB' stands for\n1,000,000 bytes.\n\nA block size specification preceded by ''' causes output sizes to be\ndisplayed with thousands separators.  The 'LCNUMERIC' locale specifies\nthe thousands separator and grouping.  For example, in an American\nEnglish locale, '--block-size=\"'1kB\"' would cause a size of 1234000\nbytes to be displayed as '1,234'.  In the default C locale, there is no\nthousands separator so a leading ''' has no effect.\n\nAn integer block size can be followed by a suffix to specify a\nmultiple of that size.  A bare size letter, or one followed by 'iB',\nspecifies a multiple using powers of 1024.  A size letter followed by\n'B' specifies powers of 1000 instead.  For example, '1M' and '1MiB' are\nequivalent to '1048576', whereas '1MB' is equivalent to '1000000'.\n\nA plain suffix without a preceding integer acts as if '1' were\nprepended, except that it causes a size indication to be appended to the\noutput.  For example, '--block-size=\"kB\"' displays 3000 as '3kB'.\n\nThe following suffixes are defined.  Large sizes like '1Q' may be\nrejected by your computer due to limitations of its arithmetic.\n\n'kB'\nkilobyte: 10^3 = 1000.\n'k'\n'K'\n'KiB'\nkibibyte: 2^{10} = 1024.  'K' is special: the SI prefix is 'k' and\nthe ISO/IEC 80000-13 prefix is 'Ki', but tradition and POSIX use\n'k' to mean 'KiB'.\n'MB'\nmegabyte: 10^6 = 1,000,000.\n'M'\n'MiB'\nmebibyte: 2^{20} = 1,048,576.\n'GB'\ngigabyte: 10^9 = 1,000,000,000.\n'G'\n'GiB'\ngibibyte: 2^{30} = 1,073,741,824.\n'TB'\nterabyte: 10^{12} = 1,000,000,000,000.\n'T'\n'TiB'\ntebibyte: 2^{40} = 1,099,511,627,776.\n'PB'\npetabyte: 10^{15} = 1,000,000,000,000,000.\n'P'\n'PiB'\npebibyte: 2^{50} = 1,125,899,906,842,624.\n'EB'\nexabyte: 10^{18} = 1,000,000,000,000,000,000.\n'E'\n'EiB'\nexbibyte: 2^{60} = 1,152,921,504,606,846,976.\n'ZB'\nzettabyte: 10^{21} = 1,000,000,000,000,000,000,000\n'Z'\n'ZiB'\nzebibyte: 2^{70} = 1,180,591,620,717,411,303,424.\n'YB'\nyottabyte: 10^{24} = 1,000,000,000,000,000,000,000,000.\n'Y'\n'YiB'\nyobibyte: 2^{80} = 1,208,925,819,614,629,174,706,176.\n'RB'\nronnabyte: 10^{27} = 1,000,000,000,000,000,000,000,000,000.\n'R'\n'RiB'\nrobibyte: 2^{90} = 1,237,940,039,285,380,274,899,124,224.\n'QB'\nquettabyte: 10^{30} = 1,000,000,000,000,000,000,000,000,000,000.\n'Q'\n'QiB'\nquebibyte: 2^{100} = 1,267,650,600,228,229,401,496,703,205,376.\n\nBlock size defaults can be overridden by an explicit\n'--block-size=SIZE' option.  The '-k' option is equivalent to\n'--block-size=1K', which is the default unless the 'POSIXLYCORRECT'\nenvironment variable is set.  The '-h' or '--human-readable' option is\nequivalent to '--block-size=human-readable'.  The '--si' option is\nequivalent to '--block-size=si'.  Note for 'ls' the '-k' option does not\ncontrol the display of the apparent file sizes, whereas the\n'--block-size' option does.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Signal specifications,  Next: Disambiguating names and IDs,  Prev: Block size,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.3 Signal specifications",
                    "content": "A SIGNAL may be a signal name like 'HUP', or a signal number like '1',\nor an exit status of a process terminated by the signal.  A signal name\ncan be given in canonical form or prefixed by 'SIG'.  The case of the\nletters is ignored.  The following signal names and numbers are\nsupported on all POSIX compliant systems:\n\n'HUP'\n1.  Hangup.\n'INT'\n2.  Terminal interrupt.\n'QUIT'\n3.  Terminal quit.\n'ABRT'\n6.  Process abort.\n'KILL'\n9.  Kill (cannot be caught or ignored).\n'ALRM'\n14.  Alarm Clock.\n'TERM'\n15.  Termination.\n"
                }
            ]
        },
        "Other supported signal names have system-dependent corresponding": {
            "content": "numbers.  All systems conforming to POSIX 1003.1-2001 also support the\nfollowing signals:\n\n'BUS'\nAccess to an undefined portion of a memory object.\n'CHLD'\nChild process terminated, stopped, or continued.\n'CONT'\nContinue executing, if stopped.\n'FPE'\nErroneous arithmetic operation.\n'ILL'\nIllegal Instruction.\n'PIPE'\nWrite on a pipe with no one to read it.\n'SEGV'\nInvalid memory reference.\n'STOP'\nStop executing (cannot be caught or ignored).\n'TSTP'\nTerminal stop.\n'TTIN'\nBackground process attempting read.\n'TTOU'\nBackground process attempting write.\n'URG'\nHigh bandwidth data is available at a socket.\n'USR1'\nUser-defined signal 1.\n'USR2'\nUser-defined signal 2.\n\nPOSIX 1003.1-2001 systems that support the XSI extension also support\nthe following signals:\n\n'POLL'\nPollable event.\n'PROF'\nProfiling timer expired.\n'SYS'\nBad system call.\n'TRAP'\nTrace/breakpoint trap.\n'VTALRM'\nVirtual timer expired.\n'XCPU'\nCPU time limit exceeded.\n'XFSZ'\nFile size limit exceeded.\n\nPOSIX 1003.1-2001 systems that support the XRT extension also support at\nleast eight real-time signals called 'RTMIN', 'RTMIN+1', ..., 'RTMAX-1',\n'RTMAX'.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Disambiguating names and IDs,  Next: Random sources,  Prev: Signal specifications,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.4 chown, chgrp, chroot, id: Disambiguating user names and IDs",
                    "content": ""
                }
            ]
        },
        "Since the USER and GROUP arguments to these commands may be specified as": {
            "content": "names or numeric IDs, there is an apparent ambiguity.  What if a user or\ngroup name is a string of digits?  Should the command interpret it as\na user name or as an ID?  (Using a number as a user name is common in\nsome environments.)  POSIX requires that these commands first attempt to\nresolve the specified string as a name, and only once that fails, then\ntry to interpret it as an ID.  This is troublesome when you want to\nspecify a numeric ID, say 42, and it must work even in a pathological\nsituation where '42' is a user name that maps to some other user ID, say\n1000.  Simply invoking 'chown 42 F', will set 'F's owner ID to 1000 -\nnot what you intended.\n\nGNU 'chown', 'chgrp', 'chroot', and 'id' provide a way to work around\nthis, that at the same time may result in a significant performance\nimprovement by eliminating a database look-up.  Simply precede each\nnumeric user ID and/or group ID with a '+', in order to force its\ninterpretation as an integer:\n\nchown +42 F\nchgrp +$numericgroupid another-file\nchown +0:+0 /\n\nThe name look-up process is skipped for each '+'-prefixed string,\nbecause a string containing '+' is never a valid user or group name.",
            "subsections": []
        },
        "This syntax is accepted on most common Unix systems, but not on Solaris": {
            "content": "10.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Random sources,  Next: Target directory,  Prev: Disambiguating names and IDs,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.5 Sources of random data",
                    "content": ""
                }
            ]
        },
        "The 'shuf', 'shred', and 'sort' commands sometimes need random data to": {
            "content": "do their work.  For example, 'sort -R' must choose a hash function at\nrandom, and it needs random data to make this selection.\n\nBy default these commands use an internal pseudo-random generator\ninitialized by a small amount of entropy, but can be directed to use an\nexternal source with the '--random-source=FILE' option.  An error is\nreported if FILE does not contain enough bytes.\n\nFor example, the device file '/dev/urandom' could be used as the\nsource of random data.  Typically, this device gathers environmental\nnoise from device drivers and other sources into an entropy pool, and\nuses the pool to generate random bits.  If the pool is short of data,\nthe device reuses the internal pool to produce more bits, using a\ncryptographically secure pseudo-random number generator.  But be aware\nthat this device is not designed for bulk random data generation and is\nrelatively slow.\n\n'/dev/urandom' suffices for most practical uses, but applications\nrequiring high-value or long-term protection of private data may require\nan alternate data source like '/dev/random' or '/dev/arandom'.  The set\nof available sources depends on your operating system.\n\nTo reproduce the results of an earlier invocation of a command, you\ncan save some random data into a file and then use that file as the\nrandom source in earlier and later invocations of the command.  Rather\nthan depending on a file, one can generate a reproducible arbitrary\namount of pseudo-random data given a seed value, using for example:\n\ngetseededrandom()\n{\nseed=\"$1\"\nopenssl enc -aes-256-ctr -pass pass:\"$seed\" -nosalt \\\n</dev/zero 2>/dev/null\n}\n\nshuf -i1-100 --random-source=<(getseededrandom 42)\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Target directory,  Next: Trailing slashes,  Prev: Random sources,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.6 Target directory",
                    "content": ""
                }
            ]
        },
        "The 'cp', 'install', 'ln', and 'mv' commands normally treat the last": {
            "content": "operand specially when it is a directory or a symbolic link to a\ndirectory.  For example, 'cp source dest' is equivalent to 'cp source\ndest/source' if 'dest' is a directory.  Sometimes this behavior is not\nexactly what is wanted, so these commands support the following options\nto allow more fine-grained control:\n\n'-T'\n'--no-target-directory'\nDo not treat the last operand specially when it is a directory or a\nsymbolic link to a directory.  This can help avoid race conditions\nin programs that operate in a shared area.  For example, when the\ncommand 'mv /tmp/source /tmp/dest' succeeds, there is no guarantee\nthat '/tmp/source' was renamed to '/tmp/dest': it could have been\nrenamed to '/tmp/dest/source' instead, if some other process\ncreated '/tmp/dest' as a directory.  However, if 'mv -T /tmp/source\n/tmp/dest' succeeds, there is no question that '/tmp/source' was\nrenamed to '/tmp/dest'.\n\nIn the opposite situation, where you want the last operand to be\ntreated as a directory and want a diagnostic otherwise, you can use\nthe '--target-directory' ('-t') option.\n\n'-t DIRECTORY'\n'--target-directory=DIRECTORY'\nUse DIRECTORY as the directory component of each destination file\nname.\n\nThe interface for most programs is that after processing options\nand a finite (possibly zero) number of fixed-position arguments,\nthe remaining argument list is either expected to be empty, or is a\nlist of items (usually files) that will all be handled identically.\nThe 'xargs' program is designed to work well with this convention.\n\nThe commands in the 'mv'-family are unusual in that they take a\nvariable number of arguments with a special case at the end\n(namely, the target directory).  This makes it nontrivial to\nperform some operations, e.g., \"move all files from here to ../d/\",\nbecause 'mv * ../d/' might exhaust the argument space, and 'ls |\nxargs ...' doesn't have a clean way to specify an extra final\nargument for each invocation of the subject command.  (It can be\ndone by going through a shell command, but that requires more human\nlabor and brain power than it should.)\n\nThe '--target-directory' ('-t') option allows the 'cp', 'install',\n'ln', and 'mv' programs to be used conveniently with 'xargs'.  For\nexample, you can move the files from the current directory to a\nsibling directory, 'd' like this:\n\nls | xargs mv -t ../d --\n\nHowever, this doesn't move files whose names begin with '.'.  If\nyou use the GNU 'find' program, you can move those files too, with\nthis command:\n\nfind . -mindepth 1 -maxdepth 1 \\\n| xargs mv -t ../d\n\nBut both of the above approaches fail if there are no files in the\ncurrent directory, or if any file has a name containing a blank or\nsome other special characters.  The following example removes those\nlimitations and requires both GNU 'find' and GNU 'xargs':\n\nfind . -mindepth 1 -maxdepth 1 -print0 \\\n| xargs --null --no-run-if-empty \\\nmv -t ../d\n",
            "subsections": []
        },
        "The '--target-directory' ('-t') and '--no-target-directory' ('-T')": {
            "content": "options cannot be combined.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Trailing slashes,  Next: Traversing symlinks,  Prev: Target directory,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.7 Trailing slashes",
                    "content": ""
                }
            ]
        },
        "Some GNU programs (at least 'cp' and 'mv') allow you to remove any": {
            "content": "trailing slashes from each SOURCE argument before operating on it.  The\n'--strip-trailing-slashes' option enables this behavior.\n\nThis is useful when a SOURCE argument may have a trailing slash and\nspecify a symbolic link to a directory.  This scenario is in fact rather\ncommon because some shells can automatically append a trailing slash\nwhen performing file name completion on such symbolic links.  Without\nthis option, 'mv', for example, (via the system's rename function) must\ninterpret a trailing slash as a request to dereference the symbolic link\nand so must rename the indirectly referenced directory and not the\nsymbolic link.  Although it may seem surprising that such behavior be\nthe default, it is required by POSIX and is consistent with other parts\nof that standard.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Traversing symlinks,  Next: Treating / specially,  Prev: Trailing slashes,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.8 Traversing symlinks",
                    "content": ""
                }
            ]
        },
        "The following options modify how 'chown' and 'chgrp' traverse a": {
            "content": "hierarchy when the '--recursive' ('-R') option is also specified.  If\nmore than one of the following options is specified, only the final one\ntakes effect.  These options specify whether processing a symbolic link\nto a directory entails operating on just the symbolic link or on all\nfiles in the hierarchy rooted at that directory.\n\nThese options are independent of '--dereference' and\n'--no-dereference' ('-h'), which control whether to modify a symlink or\nits referent.\n\n'-H'\nIf '--recursive' ('-R') is specified and a command line argument is\na symbolic link to a directory, traverse it.\n\n'-L'\nIn a recursive traversal, traverse every symbolic link to a\ndirectory that is encountered.\n\n'-P'\nDo not traverse any symbolic links.  This is the default if none of\n'-H', '-L', or '-P' is specified.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Treating / specially,  Next: Special built-in utilities,  Prev: Traversing symlinks,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.9 Treating '/' specially",
                    "content": ""
                }
            ]
        },
        "Certain commands can operate destructively on entire hierarchies.  For": {
            "content": "example, if a user with appropriate privileges mistakenly runs 'rm -rf /\ntmp/junk', that may remove all files on the entire system.  Since there\nare so few legitimate uses for such a command, GNU 'rm' normally\ndeclines to operate on any directory that resolves to '/'.  If you\nreally want to try to remove all the files on your system, you can use\nthe '--no-preserve-root' option, but the default behavior, specified by\nthe '--preserve-root' option, is safer for most purposes.\n\nThe commands 'chgrp', 'chmod' and 'chown' can also operate\ndestructively on entire hierarchies, so they too support these options.",
            "subsections": []
        },
        "Although, unlike 'rm', they don't actually unlink files, these commands": {
            "content": "are arguably more dangerous when operating recursively on '/', since\nthey often work much more quickly, and hence damage more files before an\nalert user can interrupt them.  Tradition and POSIX require these\ncommands to operate recursively on '/', so they default to\n'--no-preserve-root', but using the '--preserve-root' option makes them\nsafer for most purposes.  For convenience you can specify\n'--preserve-root' in an alias or in a shell function.\n\nNote that the '--preserve-root' option also ensures that 'chgrp' and\n'chown' do not modify '/' even when dereferencing a symlink pointing to\n'/'.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Special built-in utilities,  Next: Exit status,  Prev: Treating / specially,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.10 Special built-in utilities",
                    "content": ""
                }
            ]
        },
        "Some programs like 'nice' can invoke other programs; for example, the": {
            "content": "command 'nice cat file' invokes the program 'cat' by executing the\ncommand 'cat file'.  However, \"special built-in utilities\" like 'exit'\ncannot be invoked this way.  For example, the command 'nice exit' does\nnot have a well-defined behavior: it may generate an error message\ninstead of exiting.\n\nHere is a list of the special built-in utilities that are\nstandardized by POSIX 1003.1-2004.\n\n. : break continue eval exec exit export readonly return set shift\ntimes trap unset\n\nFor example, because '.', ':', and 'exec' are special, the commands\n'nice . foo.sh', 'nice :', and 'nice exec pwd' do not work as you might\nexpect.\n\nMany shells extend this list.  For example, Bash has several extra\nspecial built-in utilities like 'history', and 'suspend', and with Bash\nthe command 'nice suspend' generates an error message instead of\nsuspending.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Exit status,  Next: Floating point,  Prev: Special built-in utilities,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.11 Exit status",
                    "content": "Nearly every command invocation yields an integral \"exit status\" that\ncan be used to change how other commands work.  For the vast majority of\ncommands, an exit status of zero indicates success.  Failure is\nindicated by a nonzero value - typically '1', though it may differ on\nunusual platforms as POSIX requires only that it be nonzero.\n\nHowever, some of the programs documented here do produce other exit\nstatus values and a few associate different meanings with the values '0'\nand '1'.  Here are the exceptions: 'chroot', 'env', 'expr', 'ls',\n'nice', 'nohup', 'numfmt', 'printenv', 'runcon', 'sort', 'stdbuf',\n'test', 'timeout', 'tty'.\n"
                }
            ]
        },
        "File: coreutils.info,  Node: Floating point,  Next: Standards conformance,  Prev: Exit status,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.12 Floating point numbers",
                    "content": ""
                }
            ]
        },
        "Commands that accept or produce floating point numbers employ the": {
            "content": "floating point representation of the underlying system, and suffer from\nrounding error, overflow, and similar floating-point issues.  Almost all\nmodern systems use IEEE-754 floating point, and it is typically portable\nto assume IEEE-754 behavior these days.  IEEE-754 has positive and\nnegative infinity, distinguishes positive from negative zero, and uses\nspecial values called NaNs to represent invalid computations such as\ndividing zero by itself.  For more information, please see David",
            "subsections": []
        },
        "Goldberg's paper What Every Computer Scientist Should Know About": {
            "content": "",
            "subsections": []
        },
        "Floating-Point Arithmetic": {
            "content": "(https://docs.oracle.com/cd/E19957-01/806-3568/ncggoldberg.html).\n\nCommands that accept floating point numbers as options, operands or\ninput use the standard C functions 'strtod' and 'strtold' to convert\nfrom text to floating point numbers.  These floating point numbers\ntherefore can use scientific notation like '1.0e-34' and '-10e100'.",
            "subsections": []
        },
        "Commands that parse floating point also understand case-insensitive": {
            "content": "'inf', 'infinity', and 'NaN', although whether such values are useful\ndepends on the command in question.  Modern C implementations also\naccept hexadecimal floating point numbers such as '-0x.ep-3', which\nstands for -14/16 times 2^-3, which equals -0.109375.  *Note\n(libc)Parsing of Floats::.\n\nNormally the 'LCNUMERIC' locale determines the decimal-point\ncharacter.  However, some commands' descriptions specify that they\naccept numbers in either the current or the C locale; for example, they\ntreat '3.14' like '3,14' if the current locale uses comma as a decimal\npoint.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Standards conformance,  Next: Multi-call invocation,  Prev: Floating point,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.13 Standards conformance",
                    "content": ""
                }
            ]
        },
        "In a few cases, the GNU utilities' default behavior is incompatible with": {
            "content": "the POSIX standard.  To suppress these incompatibilities, define the\n'POSIXLYCORRECT' environment variable.  Unless you are checking for\nPOSIX conformance, you probably do not need to define 'POSIXLYCORRECT'.\n\nNewer versions of POSIX are occasionally incompatible with older\nversions.  For example, older versions of POSIX required the command\n'sort +1' to sort based on the second and succeeding fields in each\ninput line, but in POSIX 1003.1-2001 the same command is required to\nsort the file named '+1', and you must instead use the command 'sort -k\n2' to get the field-based sort.  To complicate things further, POSIX\n1003.1-2008 allows an implementation to have either the old or the new\nbehavior.\n\nThe GNU utilities normally conform to the version of POSIX that is\nstandard for your system.  To cause them to conform to a different\nversion of POSIX, define the 'POSIX2VERSION' environment variable to a\nvalue of the form YYYYMM specifying the year and month the standard was\nadopted.  Three values are currently supported for 'POSIX2VERSION':\n'199209' stands for POSIX 1003.2-1992, '200112' stands for POSIX\n1003.1-2001, and '200809' stands for POSIX 1003.1-2008.  For example, if\nyou have a POSIX 1003.1-2001 system but are running software containing\ntraditional usage like 'sort +1' or 'tail +10', you can work around the\ncompatibility problems by setting 'POSIX2VERSION=200809' in your\nenvironment.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Multi-call invocation,  Prev: Standards conformance,  Up: Common options": {
            "content": "",
            "subsections": [
                {
                    "name": "2.14 'coreutils': Multi-call program",
                    "content": ""
                }
            ]
        },
        "The 'coreutils' command invokes an individual utility, either implicitly": {
            "content": "selected by the last component of the name used to invoke 'coreutils',\nor explicitly with the '--coreutils-prog' option.  Synopsis:\n\ncoreutils --coreutils-prog=PROGRAM ...\n\nThe 'coreutils' command is not installed by default, so portable\nscripts should not rely on its existence.\n",
            "subsections": []
        }
    },
    "flags": [],
    "examples": [],
    "see_also": []
}