Adding upstream version 8.32.upstream/8.32upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 242 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 0000000..32496b2
--- /dev/null
+++ b/README
@@ -0,0 +1,242 @@
+These are the GNU core utilities.  This package is the union of
+the GNU fileutils, sh-utils, and textutils packages.
+
+Most of these programs have significant advantages over their Unix
+counterparts, such as greater speed, additional options, and fewer
+arbitrary limits.
+
+The programs that can be built with this package are:
+
+  [ arch b2sum base32 base64 basename basenc cat chcon chgrp chmod chown
+  chroot cksum comm coreutils cp csplit cut date dd df dir dircolors dirname
+  du echo env expand expr factor false fmt fold groups head hostid hostname
+  id install join kill link ln logname ls md5sum mkdir mkfifo mknod mktemp
+  mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx
+  pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum
+  sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync
+  tac tail tee test timeout touch tr true truncate tsort tty uname unexpand
+  uniq unlink uptime users vdir wc who whoami yes
+
+See the file NEWS for a list of major changes in the current release.
+
+If you obtained this file as part of a "git clone", then see the
+README-hacking file.  If this file came to you as part of a tar archive,
+then see the file INSTALL for compilation and installation instructions.
+
+Like the rest of the GNU system, these programs mostly conform to
+POSIX, with BSD and other extensions.  For closer conformance, or
+conformance to a particular POSIX version, set the POSIXLY_CORRECT
+and the _POSIX2_VERSION environment variables, as described in
+the documentation under "Standards conformance".
+
+The ls, dir, and vdir commands are all separate executables instead of
+one program that checks argv[0] because people often rename these
+programs to things like gls, gnuls, l, etc.  Renaming a program
+file shouldn't affect how it operates, so that people can get the
+behavior they want with whatever name they want.
+
+Special thanks to Paul Eggert, Brian Matthews, Bruce Evans, Karl Berry,
+Kaveh Ghazi, and François Pinard for help with debugging and porting
+these programs.  Many thanks to all of the people who have taken the
+time to submit problem reports and fixes.  All contributed changes are
+attributed in the commit logs.
+
+And thanks to the following people who have provided accounts for
+portability testing on many different types of systems: Bob Proulx,
+Christian Robert, François Pinard, Greg McGary, Harlan Stenn,
+Joel N. Weber, Mark D. Roth, Matt Schalit, Nelson H. F. Beebe,
+Réjean Payette, Sam Tardieu.
+
+Thanks to Michael Stone for inflicting test releases of this package
+on Debian's unstable distribution, and to all the kind folks who used
+that distribution and found and reported bugs.
+
+Note that each man page is now automatically generated from a template
+and from the corresponding --help usage message.  Patches to the template
+files (man/*.x) are welcome.  However, the authoritative documentation
+is in texinfo form in the doc directory.
+
+
+*********************
+Pre-C99 build failure
+---------------------
+
+In 2009 we added this requirement:
+To build the coreutils from source, you must have a C99-conforming
+compiler, due to the use of declarations after non-declaration statements
+in several files in src/.  There is code in configure to find and, if
+possible, enable an appropriate compiler.  However, if configure doesn't
+find a C99 compiler, it continues nonetheless, and your build will fail.
+There used to be a "c99-to-c89.diff" patch you could apply to convert
+to code that even an old pre-c99 compiler can handle, but it was too
+tedious to maintain, so has been removed.
+
+
+***********************
+HPUX 11.x build failure
+-----------------------
+
+A known problem exists when compiling on HPUX on both hppa and ia64
+in 64-bit mode (i.e., +DD64) on HP-UX 11.0, 11.11, and 11.23.  This
+is not due to a bug in the package but instead due to a bug in the
+system header file which breaks things in 64-bit mode.  The default
+compilation mode is 32-bit and the software compiles fine using the
+default mode.  To build this software in 64-bit mode you will need
+to fix the system /usr/include/inttypes.h header file.  After
+correcting that file the software also compiles fine in 64-bit mode.
+Here is one possible patch to correct the problem:
+
+--- /usr/include/inttypes.h.orig	Thu May 30 01:00:00 1996
++++ /usr/include/inttypes.h	Sun Mar 23 00:20:36 2003
+@@ -489 +489 @@
+-#ifndef __STDC_32_MODE__
++#ifndef __LP64__
+
+
+************************
+OSF/1 4.0d and AIX build failures
+------------------------
+
+If you use /usr/bin/make on these systems, the build will fail due
+to the presence of the "[" target.  OSF/1 make(1) appears to
+treat "[" as some syntax relating to locks, while AIX make(1)
+appears to skip the "[" target.  To work around these issues
+the best solution is to use GNU make.  Otherwise, simply remove
+all mention of "[$(EXEEXT)" from src/Makefile.
+
+
+************************
+32 bit time_t build failures
+------------------------
+
+On systems where it's determined that 64 bit time_t is supported
+(indicated by touch -t <some time after 2038>), but that coreutils
+would be built with a narrower time_t, the build will fail.
+This can be allowed by passing TIME_T_32_BIT_OK=yes to configure,
+or avoided by enabling 64 bit builds.  For example GCC on AIX defaults
+to 32 bit, and to enable the 64 bit ABI one can use:
+./configure CFLAGS=-maix64 LDFLAGs=-maix64 AR='ar -X64'
+
+
+*************************************************
+"make check" failure on IRIX 6.5 and Solaris <= 9
+-------------------------------------------------
+
+Using the vendor make program to run "make check" fails on these two systems.
+If you want to run all of the tests there, use GNU make.
+
+
+
+**********************
+Running tests as root:
+----------------------
+
+If you run the tests as root, note that a few of them create files
+and/or run programs as a non-root user, 'nobody' by default.
+If you want to use some other non-root username, specify it via
+the NON_ROOT_USERNAME environment variable.  Depending on the
+permissions with which the working directories have been created,
+using 'nobody' may fail, because that user won't have the required
+read and write access to the build and test directories.
+I find that it is best to unpack and build as a non-privileged
+user, and then to run the following command as that user in order
+to run the privilege-requiring tests:
+
+  sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root
+
+If you can run the tests as root, please do so and report any
+problems.  We get much less test coverage in that mode, and it's
+arguably more important that these tools work well when run by
+root than when run by less privileged users.
+
+
+***************
+Reporting bugs:
+---------------
+
+Send bug reports, questions, comments, etc. to bug-coreutils@gnu.org.
+To suggest a patch, see the files README-hacking and HACKING for tips.
+
+If you have a problem with 'sort', try running 'sort --debug', as it
+can can often help find and fix problems without having to wait for an
+answer to a bug report.  If the debug output does not suffice to fix
+the problem on your own, please compress and attach it to the rest of
+your bug report.
+
+IMPORTANT: if you take the time to report a test failure,
+please be sure to include the output of running 'make check'
+in verbose mode for each failing test.  For example,
+if the test that fails is tests/df/df-P.sh, then you would
+run this command:
+
+  make check TESTS=tests/df/df-P.sh VERBOSE=yes SUBDIRS=. >> log 2>&1
+
+For some tests, you can get even more detail by adding DEBUG=yes.
+Then include the contents of the file 'log' in your bug report.
+
+
+***************************************
+
+There are many tests, but nowhere near as many as we need.
+Additions and corrections are very welcome.
+
+If you see a problem that you've already reported, feel free to re-report
+it -- it won't bother me to get a reminder.  Besides, the more messages I
+get regarding a particular problem the sooner it'll be fixed -- usually.
+If you sent a complete patch and, after a couple weeks you haven't
+received any acknowledgement, please ping us.  A complete patch includes
+a well-written ChangeLog entry, unified (diff -u format) diffs relative
+to the most recent test release (or, better, relative to the latest
+sources in the public repository), an explanation for why the patch is
+necessary or useful, and if at all possible, enough information to
+reproduce whatever problem prompted it.  Plus, you'll earn lots of
+karma if you include a test case to exercise any bug(s) you fix.
+Here are instructions for checking out the latest development sources:
+
+  https://savannah.gnu.org/git/?group=coreutils
+
+If your patch adds a new feature, please try to get some sort of consensus
+that it is a worthwhile change.  One way to do that is to send mail to
+coreutils@gnu.org including as much description and justification
+as you can.  Based on the feedback that generates, you may be able to
+convince us that it's worth adding.  Please also consult the list of
+previously discussed but ultimately rejected feature requests at:
+https://www.gnu.org/software/coreutils/rejected_requests.html
+
+
+WARNING:  Now that we use the ./bootstrap script, you should not run
+autoreconf manually.  Doing that will overwrite essential source files
+with older versions, which may make the package unbuildable or introduce
+subtle bugs.
+
+
+WARNING:  If you modify files like configure.in, m4/*.m4, aclocal.m4,
+or any Makefile.am, then don't be surprised if what gets regenerated no
+longer works.  To make things work, you'll have to be using appropriate
+versions of the tools listed in bootstrap.conf's buildreq string.
+
+All of these programs except 'test' recognize the '--version' option.
+When reporting bugs, please include in the subject line both the package
+name/version and the name of the program for which you found a problem.
+
+For general documentation on the coding and usage standards
+this distribution follows, see the GNU Coding Standards at:
+https://www.gnu.org/prep/standards/
+
+For any copyright year range specified as YYYY-ZZZZ in this package
+note that the range specifies every single year in that closed interval.
+
+Mail suggestions and bug reports for these programs to
+the address on the last line of --help output.
+
+
+========================================================================
+
+Copyright (C) 1998-2020 Free Software Foundation, Inc.
+
+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 no
+Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
+Texts.  A copy of the license is included in the "GNU Free
+Documentation License" file as part of this distribution.