README

   1 These are the GNU core utilities.  This package is the union of
   2 the GNU fileutils, sh-utils, and textutils packages.
   3
   4 Most of these programs have significant advantages over their Unix
   5 counterparts, such as greater speed, additional options, and fewer
   6 arbitrary limits.
   7
   8 The programs that can be built with this package are:
   9
  10   [ basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd
  11   df dir dircolors dirname du echo env expand expr factor false fmt fold
  12   ginstall groups head hostid hostname id join kill link ln logname ls
  13   md5sum mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr
  14   printenv printf ptx pwd readlink rm rmdir seq sha1sum shred sleep sort
  15   split stat stty su sum sync tac tail tee test touch tr true tsort tty
  16   uname unexpand uniq unlink uptime users vdir wc who whoami yes
  17
  18 See the file NEWS for a list of major changes in the current release.
  19
  20 See the file INSTALL for compilation and installation instructions.
  21
  22 These programs are intended to conform to POSIX (with BSD and other
  23 extensions), like the rest of the GNU system.  By default they conform
  24 to older POSIX (1003.2-1992), and therefore support obsolete usages
  25 like "head -10" and "chown owner.group file".  This default is
  26 overridden at build-time by the value of <unistd.h>'s _POSIX2_VERSION
  27 macro, and this in turn can be overridden at runtime as described in
  28 the documentation under "Standards conformance".
  29
  30 The ls, dir, and vdir commands are all separate executables instead of
  31 one program that checks argv[0] because people often rename these
  32 programs to things like gls, gnuls, l, etc.  Renaming a program
  33 file shouldn't affect how it operates, so that people can get the
  34 behavior they want with whatever name they want.
  35
  36 Special thanks to Paul Eggert, Brian Matthews, Bruce Evans, Karl Berry,
  37 Kaveh Ghazi, and François Pinard for help with debugging and porting
  38 these programs.  Many thanks to all of the people who have taken the
  39 time to submit problem reports and fixes.  All contributed changes are
  40 attributed in the ChangeLog file.
  41
  42 And thanks to the following people who have provided accounts for
  43 portability testing on many different types of systems: Bob Proulx,
  44 Christian Robert, François Pinard, Greg McGary, Harlan Stenn,
  45 Joel N. Weber, Mark D. Roth, Matt Schalit, Nelson H. F. Beebe,
  46 Réjean Payette, Sam Tardieu.
  47
  48 Thanks to Michael Stone for inflicting test releases of the fileutils
  49 on Debian's unstable distribution, and to all the kind folks who used
  50 that distribution and found and reported bugs.
  51
  52 Note that each man page is now automatically generated from a template
  53 and from the corresponding --help usage message.  Patches to the template
  54 files (man/*.x) are welcome.  However, the authoritative documentation
  55 is in texinfo form in the doc directory.
  56
  57 If you run the tests on a SunOS4.1.4 system, expect the ctime-part of
  58 the ls `time-1' test to fail.  I believe that is due to a bug in the
  59 way Sun implemented link(2) and chmod(2).
  60
  61 ***************************************
  62 Last-minute notes, before coreutils-5.0
  63 ---------------------------------------
  64
  65 A known problem exists when compiling on HPUX on both hppa and ia64
  66 in 64-bit mode (i.e. +DD64) on all known HPUX 11.x versions.  This
  67 is not due to a bug in the package but instead due to a bug in the
  68 system header file which breaks things in 64-bit mode.  The default
  69 compilation mode is 32-bit and the software compiles fine using the
  70 default mode.  To build this software in 64-bit mode you will need
  71 to fix the system /usr/include/inttypes.h header file.  After
  72 correcting that file the software also compiles fine in 64-bit mode.
  73 Here is one possible patch to correct the problem.
  74
  75 --- /usr/include/inttypes.h.orig        Thu May 30 01:00:00 1996
  76 +++ /usr/include/inttypes.h     Sun Mar 23 00:20:36 2003
  77 @@ -489 +489 @@
  78 -#ifndef __STDC_32_MODE__
  79 +#ifndef __LP64__
  80
  81 If you run the tests as root, note that a few of them create files
  82 and/or run programs as a non-root user, `nobody' by default.
  83 If you want to use some other non-root username, specify it via
  84 the NON_ROOT_USERNAME environment variable.  Depending on the
  85 permissions with which the working directories have been created,
  86 using `nobody' may fail, because that user won't have the required
  87 read and write access to the build and test directories.
  88 I find that it is best to unpack and build as a non-privileged
  89 user, and then to run the following command as that user in order
  90 to run the privilege-requiring tests:
  91
  92   sudo env NON_ROOT_USERNAME=$USER make check
  93
  94 If you can run the tests as root, please do so and report any
  95 problems.  We get much less test coverage in that mode, and it's
  96 arguably more important that these tools work well when run by
  97 root than when run by less privileged users.
  98
  99 ***************************************
 100
 101 There are pretty many tests, but nowhere near as many as we need.
 102 Additions and corrections are very welcome.
 103
 104 If you see a problem that you've already reported, feel free to re-report
 105 it -- it won't bother me to get a reminder.  Besides, the more messages I
 106 get regarding a particular problem the sooner it'll be fixed -- usually.
 107 If you sent a complete patch and, after a couple weeks you haven't
 108 received any acknowledgement, please ping us.  A complete patch includes
 109 a well-written ChangeLog entry, unified (diff -u format) diffs relative
 110 to the most recent test release (or, better, relative to the latest
 111 sources in the CVS repository), an explanation for why the patch is
 112 necessary or useful, and if at all possible, enough information to
 113 reproduce whatever problem prompted it.  Plus, you'll earn lots of
 114 karma if you include a test case to exercise any bug(s) you fix.
 115 Instructions for checking out the latest source via CVS are here:
 116
 117   http://savannah.gnu.org/cvs/?group=coreutils
 118
 119
 120 If your patch adds a new feature, please try to get some sort of consensus
 121 that it is a worthwhile change.  One way to do that is to send mail to
 122 bug-coreutils@gnu.org including as much description and justification
 123 as you can.  Based on the feedback that generates, you may be able to
 124 convince us that it's worth adding.
 125
 126
 127 WARNING:  If you modify files like configure.in, m4/*.m4, aclocal.m4,
 128 or any Makefile.am, then don't be surprised if what gets regenerated no
 129 longer works.  To make things work, you'll have to be using appropriate
 130 versions of automake and autoconf.  As for what versions are `appropriate',
 131 use the versions of
 132
 133   * autoconf specified via AC_PREREQ in m4/jm-macros.m4
 134   * automake specified via AM_INIT_AUTOMAKE in configure.ac
 135
 136 Usually it's fine to use versions that are newer than those specified.
 137
 138 These programs all recognize the `--version' option.  When reporting
 139 bugs, please include in the subject line both the package name/version
 140 and the name of the program for which you found a problem.
 141
 142 For general documentation on the coding and usage standards
 143 this distribution follows, see the GNU Coding Standards,
 144 http://www.gnu.org/prep/standards_toc.html.
 145
 146 Mail suggestions and bug reports for these programs to
 147 the address on the last line of --help output.