NameDateSize

..06-Nov-20134 KiB

.gitattributes05-Mar-2012309

.gitignore09-Jun-20152.9 KiB

.gitmodules05-Mar-201289

.mailmap13-Feb-20151.8 KiB

.prev-version21-Jan-20165

.vg-suppressions03-Jan-20161.9 KiB

.x-update-copyright03-Jan-201554

AUTHORS03-Sep-20153.6 KiB

bootstrap15-Mar-201630.9 KiB

bootstrap.conf03-Jan-20167 KiB

build-aux/03-Jan-20164 KiB

cfg.mk29-Jul-201634.8 KiB

ChangeLog-200503-Jan-2016438.3 KiB

ChangeLog-200603-Jan-2016149.8 KiB

ChangeLog-200703-Jan-2016154.9 KiB

ChangeLog-200803-Jan-201613.4 KiB

configure.ac03-Jan-201621.5 KiB

COPYING05-Mar-201234.3 KiB

dist-check.mk03-Sep-20124.3 KiB

doc/09-Jul-20164 KiB

gl/20-Sep-20124 KiB

gnulib/05-Mar-20124 KiB

gnulib-tests/05-Mar-20124 KiB

HACKING03-Jan-201623.4 KiB

init.cfg17-Jan-201619.5 KiB

lib/03-Jan-20164 KiB

m4/03-Jan-20164 KiB

Makefile.am03-Jan-20168.1 KiB

man/29-Jul-20164 KiB

NEWS19-Aug-2016186.7 KiB

old/05-Mar-20124 KiB

po/11-Aug-20164 KiB

README03-Jan-201611.1 KiB

README-hacking03-Jan-20164 KiB

README-package-renamed-to-coreutils05-Mar-2012864

README-prereq01-Feb-20152.2 KiB

README-release15-Dec-20155 KiB

README-valgrind03-Jan-20161.8 KiB

scripts/19-Nov-20154 KiB

src/19-Aug-20164 KiB

tests/19-Jul-20164 KiB

thanks-gen05-Mar-2012441

THANKS.in05-Aug-201637.1 KiB

THANKStt.in05-Mar-2012121

TODO11-Aug-20166.6 KiB

README

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

README-hacking

1-*- outline -*-
2
3These notes intend to help people working on the checked-out sources.
4These requirements do not apply when building from a distribution tarball.
5See also HACKING for more detailed contribution guidelines.
6
7* Requirements
8
9We've opted to keep only the highest-level sources in the GIT repository.
10This eases our maintenance burden, (fewer merges etc.), but imposes more
11requirements on anyone wishing to build from the just-checked-out sources.
12Note the requirements to build the released archive are much less and
13are just the requirements of the standard ./configure && make procedure.
14Specific development tools and versions will be checked for and listed by
15the bootstrap script.  See README-prereq for specific notes on obtaining
16these prerequisite tools.
17
18Valgrind <http://valgrind.org/> is also highly recommended, if
19Valgrind supports your architecture. See also README-valgrind.
20
21While building from a just-cloned source tree may require installing a
22few prerequisites, later, a plain 'git pull && make' should be sufficient.
23
24* First GIT checkout
25
26You can get a copy of the source repository like this:
27
28        $ git clone git://git.sv.gnu.org/coreutils
29        $ cd coreutils
30
31As an optional step, if you already have a copy of the gnulib git
32repository, then you can use it as a reference to reduce download
33time and disk space requirements:
34
35        $ export GNULIB_SRCDIR=/path/to/gnulib
36
37The next step is to get and check other files needed to build,
38which are extracted from other source packages:
39
40        $ ./bootstrap
41
42To use the most-recent gnulib (as opposed to the gnulib version that
43the package last synchronized to), do this next:
44
45        $ git submodule foreach git pull origin master
46        $ git commit -m 'build: update gnulib submodule to latest' gnulib
47
48And there you are!  Just
49
50        $ ./configure --quiet #[--enable-gcc-warnings] [*]
51        $ make
52        $ make check
53
54At this point, there should be no difference between your local copy,
55and the GIT master copy:
56
57        $ git diff
58
59should output no difference.
60
61Enjoy!
62
63[*] The --enable-gcc-warnings option is useful only with glibc
64and with a very recent version of gcc.  You'll probably also have
65to use recent system headers.  If you configure with this option,
66and spot a problem, please be sure to send the report to the bug
67reporting address of this package, and not to that of gnulib, even
68if the problem seems to originate in a gnulib-provided file.
69
70* Submitting patches
71
72If you develop a fix or a new feature, please send it to the
73appropriate bug-reporting address as reported by the --help option of
74each program.  One way to do this is to use vc-dwim
75<http://www.gnu.org/software/vc-dwim/>), as follows.
76
77  Run the command "vc-dwim --help", copy its definition of the
78  "git-changelog-symlink-init" function into your shell, and then run
79  this function at the top-level directory of the package.
80
81  Edit the (empty) ChangeLog file that this command creates, creating a
82  properly-formatted entry according to the GNU coding standards
83  <http://www.gnu.org/prep/standards/html_node/Change-Logs.html>.
84
85  Make your changes.
86
87  Run the command "vc-dwim" and make sure its output (the diff of all
88  your changes) looks good.
89
90  Run "vc-dwim --commit".
91
92  Run the command "git format-patch --stdout -1", and email its output
93  in, using the output's subject line.
94
95-----
96
97Copyright (C) 2002-2016 Free Software Foundation, Inc.
98
99This program is free software: you can redistribute it and/or modify
100it under the terms of the GNU General Public License as published by
101the Free Software Foundation, either version 3 of the License, or
102(at your option) any later version.
103
104This program is distributed in the hope that it will be useful,
105but WITHOUT ANY WARRANTY; without even the implied warranty of
106MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
107GNU General Public License for more details.
108
109You should have received a copy of the GNU General Public License
110along with this program.  If not, see <http://www.gnu.org/licenses/>.
111

README-package-renamed-to-coreutils

1As of 2002-09-01, the GNU fileutils, textutils, and sh-utils
2packages have been merged into one, called the GNU coreutils.
3See http://www.gnu.org/software/coreutils/ for a description.
4Here's the FAQ list:
5
6  http://www.gnu.org/software/coreutils/faq/
7
8For information on the mailing lists associated with the
9coreutils package, see these:
10
11  http://mail.gnu.org/mailman/listinfo/coreutils-announce
12  http://mail.gnu.org/mailman/listinfo/bug-coreutils
13  http://mail.gnu.org/mailman/listinfo/coreutils
14
15mailing list archives are here:
16
17  http://news.gmane.org/gmane.comp.gnu.coreutils.announce
18  http://news.gmane.org/gmane.comp.gnu.core-utils.bugs (up to the minute)
19  http://mail.gnu.org/pipermail/bug-coreutils/ (updated every 12 hours)
20  http://news.gmane.org/gmane.comp.gnu.coreutils.general
21  http://mail.gnu.org/pipermail/coreutils/ (updated every 12 hours)
22

README-prereq

1This gives some notes on obtaining the tools required for development.
2I.e., the tools checked for by the bootstrap script and include:
3
4- Autoconf  <http://www.gnu.org/software/autoconf/>
5- Automake  <http://www.gnu.org/software/automake/>
6- Bison     <http://www.gnu.org/software/bison/>
7- Gettext   <http://www.gnu.org/software/gettext/>
8- Git       <http://git.or.cz/>
9- Gperf     <http://www.gnu.org/software/gperf/>
10- Gzip      <http://www.gnu.org/software/gzip/>
11- Perl      <http://www.cpan.org/>
12- Rsync     <http://samba.anu.edu.au/rsync/>
13- Tar       <http://www.gnu.org/software/tar/>
14- Texinfo   <http://www.gnu.org/software/texinfo/>
15
16Note please try to install/build official packages for your system.
17If these programs are not available use the following instructions
18to build them and install the results into a directory that you will
19then use when building this package.
20
21Even if the official version of a package for your system is too old,
22please install it, as it may be required to build the newer versions.
23The examples below install into $HOME/coreutils/deps/, so if you are
24going to follow these instructions, first ensure that your $PATH is
25set correctly by running this command:
26
27  prefix=$HOME/coreutils/deps
28  export PATH=$prefix/bin:$PATH
29
30* autoconf *
31
32  # Note Autoconf 2.62 or newer is needed to build automake-1.11.2
33  # but we specify 2.64 here as that's what coreutils requires.
34  # Please use the latest stable release version as indicated by git tags.
35  git clone --depth=1 git://git.sv.gnu.org/autoconf.git
36  cd autoconf
37  git checkout v2.64
38  autoreconf -vi
39  ./configure --prefix=$prefix
40  make install
41
42* automake *
43
44  # Note help2man is required to build automake fully
45  git clone git://git.sv.gnu.org/automake.git
46  cd automake
47  git checkout v1.11.2
48  ./bootstrap
49  ./configure --prefix=$prefix
50  make install
51
52This package uses XZ utils (successor to LZMA) to create
53a compressed distribution tarball.  Using this feature of Automake
54requires version 1.10a or newer, as well as the xz program itself.
55
56* xz *
57
58  git clone git://ctrl.tukaani.org/xz.git
59  cd xz
60  ./autogen.sh
61  ./configure --prefix=$prefix
62  make install
63
64Now you can build this package as described in README-hacking.
65

README-release

1Here are most of the steps we (maintainers) follow when making a release.
2
3* start from a clean, up-to-date git directory.
4
5    git checkout master; git pull
6
7* Run ./configure && make maintainer-clean
8
9* Ensure that the desired versions of autoconf, automake, bison, etc.
10  are in your PATH.  See the buildreq list in bootstrap.conf for
11  the complete list.
12
13* Ensure that you're on "master" with no uncommitted diffs.
14  This should produce no output: git checkout master; git diff
15
16* Ensure that you've pushed all changes that belong in the release
17  and that the NixOS/Hydra autobuilder is reporting all is well:
18
19      http://hydra.nixos.org/jobset/gnu/coreutils-master
20
21* Run bootstrap one last time.  This downloads any new translations:
22
23    ./bootstrap
24
25FIXME: enable excluded programs like arch? to get their manual pages?
26
27* Check for new file system types by running the following command on
28  a system with the most recent kernel possible (e.g., Fedora rawhide):
29
30    make src/fs-magic-compare
31
32  Or download the latest header first like:
33
34    kgit='https://git.kernel.org/cgit/linux/kernel/git'
35    wget -q $kgit/torvalds/linux.git/plain/include/uapi/linux/magic.h \
36      -O src/fs-latest-magic.h
37
38  If it finds a new file system magic number, add it to src/stat.c.
39  If it is a remote file system tag it as such.
40
41  Note there may be some new file systems magic values not defined
42  in that linux/magic.h file, which can be seen at:
43
44    https://www.livegrep.com/search/linux\
45    ?q=%23define+.*_SUPER_MAGIC+-file%3Amagic\.h
46
47
48* Pre-release testing:
49
50  Run the following on at least one SELinux-enabled (enforcing) and
51  one non-SELinux system:
52
53    n=$(( ($(nproc) + 1) / 2 ))
54    sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER \
55      make -k -j$(nproc) check-root SUBDIRS=. \
56      && make distcheck \
57      && make -j$n check RUN_VERY_EXPENSIVE_TESTS=yes RUN_EXPENSIVE_TESTS=yes
58
59  If testing on systems with a non standard default shell, spurious failures
60  may occur.  Often there are other shells available, and you can select
61  those by using for example, SHELL=bash in the commands above.
62
63  Note that the use of -j$n tells make to use approximately half of the
64  available processing units.  If you use -jN, for larger N, some of the
65  expensive tests are likely to interfere with concurrent performance-measuring
66  or timing-sensitive tests, resulting in spurious failures.
67
68  If "make distcheck" doesn't run "make syntax-check" for you, then run
69  it manually:
70
71    make syntax-check
72
73* To set the date, version number, and release type [stable/alpha/beta] on
74  line 3 of NEWS, commit that, and tag the release; run:
75
76    build-aux/do-release-commit-and-tag X.Y stable
77
78* Run the following to create release tarballs.  Your choice selects the
79  corresponding upload-to destination in the emitted gnupload command.
80  The different destinations are specified in cfg.mk.  See the definitions
81  of gnu_ftp_host-{alpha,beta,stable}.
82
83    # "TYPE" must be stable, beta or alpha
84    make TYPE
85
86* Test the tarball.  copy it to a few odd-ball systems and ensure that
87  it builds and passes all tests.
88
89* While that's happening, write the release announcement that you will
90  soon post.  Start with the template, $HOME/announce-coreutils-X.Y
91  that was just created by that "make" command.
92
93  For generating counts use:
94   oldrel=$(cat .prev-version)
95   printf "There have been %d commits by %d people %s\n" \
96     $(($(git log --oneline v$oldrel.. | wc -l) - 3))    \
97     $(git shortlog v$oldrel.. | grep "^[^ ]" | wc -l)   \
98     "in the [X] weeks since $oldrel"
99
100   git shortlog v$oldrel.. | sed -n 's/:$//p' |
101   sed 's/^/  /' | column -c 70 | expand
102
103Once all the builds and tests have passed,
104
105* Run the gnupload command that was suggested by your "make stable" run above.
106
107* Wait a few minutes (maybe up to 30?) and then use the release URLs to
108  download all tarball/signature pairs and use gpg --verify to ensure
109  that they're all valid.
110
111* Push the NEWS-updating changes and the new tag:
112
113    v=$(cat .prev-version)
114    git push origin master tag v$v
115
116* Announce it on Savannah first, so you can include the preferable
117  savannah.org announcement link in the email message.
118
119  From here:
120    https://savannah.gnu.org/projects/coreutils/
121  click on the "submit news", then write something like the following:
122  (If there is no such button, then enable "News" for the project via
123   the Main -> "Select Features" menu item, or via this link:
124   https://savannah.gnu.org/project/admin/editgroupfeatures.php?group=coreutils)
125
126    Subject: coreutils-X.Y released [stable]
127    +verbatim+
128    ...paste the announcement here...
129    -verbatim-
130
131  Then go here to approve it:
132    https://savannah.gnu.org/news/approve.php?group=coreutils
133
134* Send the announcement email message (signed with the release key)
135
136* Approve the announcement here:
137  http://lists.gnu.org/mailman/admindb/coreutils-announce
138
139* After each non-alpha release, update the on-line manual accessible via
140
141    http://www.gnu.org/software/coreutils/manual/
142
143  by running this:
144
145    build-aux/gnu-web-doc-update --mirror
146

README-valgrind

1#! /bin/bash
2# Convert this package for use with valgrind.
3
4# Copyright (C) 2002-2016 Free Software Foundation, Inc.
5
6# This program is free software: you can redistribute it and/or modify
7# it under the terms of the GNU General Public License as published by
8# the Free Software Foundation, either version 3 of the License, or
9# (at your option) any later version.
10
11# This program is distributed in the hope that it will be useful,
12# but WITHOUT ANY WARRANTY; without even the implied warranty of
13# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
14# GNU General Public License for more details.
15
16# You should have received a copy of the GNU General Public License
17# along with this program.  If not, see <http://www.gnu.org/licenses/>.
18
19
20
21# Convert Makefile.am files:
22#  find tests -name check.mk | xargs grep -wl PATH |
23#    xargs perl -pi -e 's,src(\$\(PATH_SEPARATOR\)),src/vg$1,'
24# To restore:
25#  find tests -name check.mk | xargs grep -wl PATH |
26#    xargs perl -pi -e 's,src/vg,src,'
27#
28# Create this symlink for suppressions (this is no longer necessary,
29# with Linux kernel 2.6.9 and valgrind-2.2.0):
30# ln -s $PWD/.vg-suppressions /tmp/cu-vg
31
32
33# Create src/vg:
34
35coreutils=$(echo 'spy:;@echo $(all_programs) $(noinst_PROGRAMS)' |
36            (cd src; make -f Makefile -f - spy | tr -s '\n ' '  '))
37mkdir -p src/vg
38pwd=`pwd`
39srcdir=$pwd/src
40_path='export PATH='$srcdir':${PATH#*:}'
41pre='#!/bin/sh\n'"$_path"'\n'
42n=15 # stack trace depth
43log_fd=3 # One can redirect this to file like 3>vg.log
44test -e /tmp/cu-vg && suppressions='--supressions=/tmp/cu-vg'
45vg="exec /usr/bin/valgrind $suppressions --log-fd=$log_fd \
46--leak-check=yes --track-fds=yes --leak-check=full --num-callers=$n"
47cat <<EOF > src/vg/gen
48for i in $coreutils; do
49  printf "$pre$vg -- \$i"' "\$@"\n' > \$i
50  chmod a+x \$i
51done
52EOF
53cd src/vg
54. ./gen
55