Name Date Size

..29-Nov-20194 KiB

.gitattributesH A D13-Aug-2017309

.github/H01-Jan-20204 KiB

.gitignoreH A D01-Jan-20203.1 KiB

.gitmodulesH A D13-Aug-201789

.mailmapH A D02-Oct-20171.8 KiB

.prev-versionH A D11-Mar-20195

.vg-suppressionsH A D01-Jan-20201.9 KiB

.x-update-copyrightH A D13-Aug-201754

AUTHORSH A D28-Dec-20183.7 KiB

bootstrapH A D01-Jan-202032.8 KiB

bootstrap.confH A D01-Jan-20207.5 KiB

build-aux/H28-Dec-20184 KiB

cfg.mkH A D01-Jan-202036 KiB

configure.acH A D01-Jan-202022.2 KiB

COPYINGH A D11-Mar-201934.3 KiB

dist-check.mkH A D13-Aug-20174.5 KiB

doc/H01-Jan-20204 KiB

gl/H13-Aug-20174 KiB

gnulib/H13-Aug-20174 KiB

gnulib-tests/H13-Aug-20174 KiB

HACKINGH A D01-Jan-202023.3 KiB

init.cfgH A D01-Jan-202020 KiB

lib/H01-Jan-20204 KiB

m4/H01-Jan-20204 KiB

Makefile.amH A D01-Jan-20207.9 KiB

man/H01-Jan-20204 KiB

NEWSH A D01-Jan-2020210.4 KiB

po/H01-Jan-20204 KiB

READMEH A D01-Jan-202010.5 KiB

README-hackingH A D01-Jan-20203.9 KiB

README-package-renamed-to-coreutilsH A D13-Aug-2017544

README-prereqH A D19-Sep-20172.2 KiB

README-releaseH A D19-Sep-20175 KiB

README-valgrindH A D01-Jan-20201.8 KiB

scripts/H15-Aug-20194 KiB

src/H01-Jan-20204 KiB

tests/H01-Jan-20204 KiB

thanks-genH A D13-Aug-2017441

THANKS.inH A D04-Aug-201937.5 KiB

THANKStt.inH A D13-Aug-2017121

TODOH A D01-Jan-20206.5 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 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

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<https://www.gnu.org/software/vc-dwim/>), as follows.
76
77  Run the command "vc-dwim --initialize" from the top-level directory
78  of this package's git-cloned hierarchy.
79
80  Edit the (empty) ChangeLog file that this command creates, creating a
81  properly-formatted entry according to the GNU coding standards
82  <https://www.gnu.org/prep/standards/html_node/Change-Logs.html>.
83
84  Make your changes.
85
86  Run the command "vc-dwim" and make sure its output (the diff of all
87  your changes) looks good.
88
89  Run "vc-dwim --commit".
90
91  Run the command "git format-patch --stdout -1", and email its output
92  in, using the output's subject line.
93
94-----
95
96Copyright (C) 2002-2020 Free Software Foundation, Inc.
97
98This program is free software: you can redistribute it and/or modify
99it under the terms of the GNU General Public License as published by
100the Free Software Foundation, either version 3 of the License, or
101(at your option) any later version.
102
103This program is distributed in the hope that it will be useful,
104but WITHOUT ANY WARRANTY; without even the implied warranty of
105MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
106GNU General Public License for more details.
107
108You should have received a copy of the GNU General Public License
109along with this program.  If not, see <https://www.gnu.org/licenses/>.
110

README-package-renamed-to-coreutils

1On 2002-09-01, the GNU fileutils, textutils, and sh-utils
2packages were merged into one, called the GNU coreutils.
3See https://www.gnu.org/software/coreutils/coreutils.html for a description.
4Here's the FAQ list:
5
6  https://www.gnu.org/software/coreutils/faq/
7
8For information on the mailing lists associated with the
9coreutils package, including archive locations, see these:
10
11  https://lists.gnu.org/mailman/listinfo/coreutils-announce
12  https://lists.gnu.org/mailman/listinfo/bug-coreutils
13  https://lists.gnu.org/mailman/listinfo/coreutils
14

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  <https://www.gnu.org/software/autoconf/>
5- Automake  <https://www.gnu.org/software/automake/>
6- Bison     <https://www.gnu.org/software/bison/>
7- Gettext   <https://www.gnu.org/software/gettext/>
8- Git       <https://git-scm.com/>
9- Gperf     <https://www.gnu.org/software/gperf/>
10- Gzip      <https://www.gnu.org/software/gzip/>
11- Perl      <https://www.cpan.org/>
12- Rsync     <https://rsync.samba.org/>
13- Tar       <https://www.gnu.org/software/tar/>
14- Texinfo   <https://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      https://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  https://lists.gnu.org/mailman/admindb/coreutils-announce
138
139* After each non-alpha release, update the on-line manual accessible via
140
141    https://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-2020 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 <https://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