summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorJim Meyering <jim@meyering.net>2002-08-04 13:40:26 +0000
committerJim Meyering <jim@meyering.net>2002-08-04 13:40:26 +0000
commit62ddac9d221240bbf790a3a6081ff27ed91d9eeb (patch)
tree98be4953fd1579cef14e0a5939b3c95192a2c1b2 /README
parenta3e653fea2ad49d71442d86ca6c7bade15168ec3 (diff)
downloadcoreutils-62ddac9d221240bbf790a3a6081ff27ed91d9eeb.tar.xz
.
Diffstat (limited to 'README')
-rw-r--r--README95
1 files changed, 95 insertions, 0 deletions
diff --git a/README b/README
new file mode 100644
index 000000000..5546d5d74
--- /dev/null
+++ b/README
@@ -0,0 +1,95 @@
+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:
+
+ basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd
+ df dir dircolors dirname du echo env expand expr factor false fmt fold
+ ginstall groups head hostid hostname id join kill link ln logname ls
+ md5sum mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr
+ printenv printf ptx pwd rm rmdir seq sha1sum shred sleep sort split
+ stat stty su sum sync tac tail tee test touch tr true 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.
+
+See the file INSTALL for compilation and installation instructions.
+
+These programs are intended to be POSIX.2 compliant (with BSD and other
+extensions), like the rest of the GNU system.
+
+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 ChangeLog file.
+
+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 the fileutils
+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.
+
+If you run the tests on a SunOS4.1.4 system, expect the ctime-part of
+the ls `time-1' test to fail. I believe that is due to a bug in the
+way Sun implemented link(2) and chmod(2).
+
+There are pretty 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,
+an explanation for why the patch is necessary or useful, and if at all
+possible, enough information to reproduce whatever problem prompted it.
+
+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
+bug-gnu-utils@gnu.org (aka the gnu.utils.bug news group) 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.
+
+
+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 automake and autoconf. As for what versions are `appropriate',
+use the versions of
+
+ * autoconf specified via AC_PREREQ in m4/jm-macros.m4
+ * automake specified via AM_INIT_AUTOMAKE in configure.ac
+
+Usually it's fine to use versions that are newer than those specified.
+
+These programs all 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,
+http://www.gnu.org/prep/standards_toc.html.
+
+Mail suggestions and bug reports for these programs to
+the address on the last line of --help output.