1These are the GNU core utilities. This package is the union of 2the GNU fileutils, sh-utils, and textutils packages. 3 4Most of these programs have significant advantages over their Unix 5counterparts, such as greater speed, additional options, and fewer 6arbitrary limits. 7 8The programs that can be built with this package are: 9 10 [ arch b2sum base32 base64 basename basenc cat chcon chgrp chmod chown 11 chroot cksum comm coreutils cp csplit cut date dd df dir dircolors dirname 12 du echo env expand expr factor false fmt fold groups head hostid hostname 13 id install join kill link ln logname ls md5sum mkdir mkfifo mknod mktemp 14 mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx 15 pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum 16 sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync 17 tac tail tee test timeout touch tr true truncate tsort tty uname unexpand 18 uniq unlink uptime users vdir wc who whoami yes 19 20See the file NEWS for a list of major changes in the current release. 21 22If you obtained this file as part of a "git clone", then see the 23README-hacking file. If this file came to you as part of a tar archive, 24then see the file INSTALL for compilation and installation instructions. 25 26Like the rest of the GNU system, these programs mostly conform to 27POSIX, with BSD and other extensions. For closer conformance, or 28conformance to a particular POSIX version, set the POSIXLY_CORRECT 29and the _POSIX2_VERSION environment variables, as described in 30the documentation under "Standards conformance". 31 32The ls, dir, and vdir commands are all separate executables instead of 33one program that checks argv[0] because people often rename these 34programs to things like gls, gnuls, l, etc. Renaming a program 35file shouldn't affect how it operates, so that people can get the 36behavior they want with whatever name they want. 37 38Special thanks to Paul Eggert, Brian Matthews, Bruce Evans, Karl Berry, 39Kaveh Ghazi, and François Pinard for help with debugging and porting 40these programs. Many thanks to all of the people who have taken the 41time to submit problem reports and fixes. All contributed changes are 42attributed in the commit logs. 43 44And thanks to the following people who have provided accounts for 45portability testing on many different types of systems: Bob Proulx, 46Christian Robert, François Pinard, Greg McGary, Harlan Stenn, 47Joel N. Weber, Mark D. Roth, Matt Schalit, Nelson H. F. Beebe, 48Réjean Payette, Sam Tardieu. 49 50Thanks to Michael Stone for inflicting test releases of this package 51on Debian's unstable distribution, and to all the kind folks who used 52that distribution and found and reported bugs. 53 54Note that each man page is now automatically generated from a template 55and from the corresponding --help usage message. Patches to the template 56files (man/*.x) are welcome. However, the authoritative documentation 57is in texinfo form in the doc directory. 58 59 60********************* 61Pre-C99 build failure 62--------------------- 63 64In 2009 we added this requirement: 65To build the coreutils from source, you must have a C99-conforming 66compiler, due to the use of declarations after non-declaration statements 67in several files in src/. There is code in configure to find and, if 68possible, enable an appropriate compiler. However, if configure doesn't 69find a C99 compiler, it continues nonetheless, and your build will fail. 70There used to be a "c99-to-c89.diff" patch you could apply to convert 71to code that even an old pre-c99 compiler can handle, but it was too 72tedious to maintain, so has been removed. 73 74 75*********************** 76HPUX 11.x build failure 77----------------------- 78 79A known problem exists when compiling on HPUX on both hppa and ia64 80in 64-bit mode (i.e., +DD64) on HP-UX 11.0, 11.11, and 11.23. This 81is not due to a bug in the package but instead due to a bug in the 82system header file which breaks things in 64-bit mode. The default 83compilation mode is 32-bit and the software compiles fine using the 84default mode. To build this software in 64-bit mode you will need 85to fix the system /usr/include/inttypes.h header file. After 86correcting that file the software also compiles fine in 64-bit mode. 87Here is one possible patch to correct the problem: 88 89--- /usr/include/inttypes.h.orig Thu May 30 01:00:00 1996 90+++ /usr/include/inttypes.h Sun Mar 23 00:20:36 2003 91@@ -489 +489 @@ 92-#ifndef __STDC_32_MODE__ 93+#ifndef __LP64__ 94 95 96************************ 97OSF/1 4.0d and AIX build failures 98------------------------ 99 100If you use /usr/bin/make on these systems, the build will fail due 101to the presence of the "[" target. OSF/1 make(1) appears to 102treat "[" as some syntax relating to locks, while AIX make(1) 103appears to skip the "[" target. To work around these issues 104the best solution is to use GNU make. Otherwise, simply remove 105all mention of "[$(EXEEXT)" from src/Makefile. 106 107 108************************ 10932 bit time_t build failures 110------------------------ 111 112On systems where it's determined that 64 bit time_t is supported 113(indicated by touch -t <some time after 2038>), but that coreutils 114would be built with a narrower time_t, the build will fail. 115This can be allowed by passing TIME_T_32_BIT_OK=yes to configure, 116or avoided by enabling 64 bit builds. For example GCC on AIX defaults 117to 32 bit, and to enable the 64 bit ABI one can use: 118./configure CFLAGS=-maix64 LDFLAGs=-maix64 AR='ar -X64' 119 120 121************************************************* 122"make check" failure on IRIX 6.5 and Solaris <= 9 123------------------------------------------------- 124 125Using the vendor make program to run "make check" fails on these two systems. 126If you want to run all of the tests there, use GNU make. 127 128 129 130********************** 131Running tests as root: 132---------------------- 133 134If you run the tests as root, note that a few of them create files 135and/or run programs as a non-root user, 'nobody' by default. 136If you want to use some other non-root username, specify it via 137the NON_ROOT_USERNAME environment variable. Depending on the 138permissions with which the working directories have been created, 139using 'nobody' may fail, because that user won't have the required 140read and write access to the build and test directories. 141I find that it is best to unpack and build as a non-privileged 142user, and then to run the following command as that user in order 143to run the privilege-requiring tests: 144 145 sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root 146 147If you can run the tests as root, please do so and report any 148problems. We get much less test coverage in that mode, and it's 149arguably more important that these tools work well when run by 150root than when run by less privileged users. 151 152 153*************** 154Reporting bugs: 155--------------- 156 157Send bug reports, questions, comments, etc. to bug-coreutils@gnu.org. 158To suggest a patch, see the files README-hacking and HACKING for tips. 159 160If you have a problem with 'sort', try running 'sort --debug', as it 161can can often help find and fix problems without having to wait for an 162answer to a bug report. If the debug output does not suffice to fix 163the problem on your own, please compress and attach it to the rest of 164your bug report. 165 166IMPORTANT: if you take the time to report a test failure, 167please be sure to include the output of running 'make check' 168in verbose mode for each failing test. For example, 169if the test that fails is tests/df/df-P.sh, then you would 170run this command: 171 172 make check TESTS=tests/df/df-P.sh VERBOSE=yes SUBDIRS=. >> log 2>&1 173 174For some tests, you can get even more detail by adding DEBUG=yes. 175Then include the contents of the file 'log' in your bug report. 176 177 178*************************************** 179 180There are many tests, but nowhere near as many as we need. 181Additions and corrections are very welcome. 182 183If you see a problem that you've already reported, feel free to re-report 184it -- it won't bother me to get a reminder. Besides, the more messages I 185get regarding a particular problem the sooner it'll be fixed -- usually. 186If you sent a complete patch and, after a couple weeks you haven't 187received any acknowledgement, please ping us. A complete patch includes 188a well-written ChangeLog entry, unified (diff -u format) diffs relative 189to the most recent test release (or, better, relative to the latest 190sources in the public repository), an explanation for why the patch is 191necessary or useful, and if at all possible, enough information to 192reproduce whatever problem prompted it. Plus, you'll earn lots of 193karma if you include a test case to exercise any bug(s) you fix. 194Here are instructions for checking out the latest development sources: 195 196 https://savannah.gnu.org/git/?group=coreutils 197 198If your patch adds a new feature, please try to get some sort of consensus 199that it is a worthwhile change. One way to do that is to send mail to 200coreutils@gnu.org including as much description and justification 201as you can. Based on the feedback that generates, you may be able to 202convince us that it's worth adding. Please also consult the list of 203previously discussed but ultimately rejected feature requests at: 204https://www.gnu.org/software/coreutils/rejected_requests.html 205 206 207WARNING: Now that we use the ./bootstrap script, you should not run 208autoreconf manually. Doing that will overwrite essential source files 209with older versions, which may make the package unbuildable or introduce 210subtle bugs. 211 212 213WARNING: If you modify files like configure.in, m4/*.m4, aclocal.m4, 214or any Makefile.am, then don't be surprised if what gets regenerated no 215longer works. To make things work, you'll have to be using appropriate 216versions of the tools listed in bootstrap.conf's buildreq string. 217 218All of these programs except 'test' recognize the '--version' option. 219When reporting bugs, please include in the subject line both the package 220name/version and the name of the program for which you found a problem. 221 222For general documentation on the coding and usage standards 223this distribution follows, see the GNU Coding Standards at: 224https://www.gnu.org/prep/standards/ 225 226For any copyright year range specified as YYYY-ZZZZ in this package 227note that the range specifies every single year in that closed interval. 228 229Mail suggestions and bug reports for these programs to 230the address on the last line of --help output. 231 232 233======================================================================== 234 235Copyright (C) 1998-2020 Free Software Foundation, Inc. 236 237Permission is granted to copy, distribute and/or modify this document 238under the terms of the GNU Free Documentation License, Version 1.3 or 239any later version published by the Free Software Foundation; with no 240Invariant Sections, with no Front-Cover Texts, and with no Back-Cover 241Texts. A copy of the license is included in the "GNU Free 242Documentation License" file as part of this distribution. 243