NameDateSize

..06-Nov-20134 KiB

.gitattributes05-Mar-2012309

.gitignore15-Jul-20142.8 KiB

.gitmodules05-Mar-201289

.mailmap25-Jun-20131.5 KiB

.prev-version19-Jul-20145

.vg-suppressions05-Jan-20141.9 KiB

.x-update-copyright05-Jan-201446

AUTHORS15-Jul-20143.6 KiB

bootstrap13-May-201430.5 KiB

bootstrap.conf15-Jul-20146.9 KiB

build-aux/19-Jul-20144 KiB

cfg.mk19-Jul-201426.2 KiB

ChangeLog-200505-Jan-2014438.3 KiB

ChangeLog-200605-Jan-2014149.8 KiB

ChangeLog-200705-Jan-2014154.9 KiB

ChangeLog-200805-Jan-201413.4 KiB

configure.ac01-Aug-201421.1 KiB

COPYING05-Mar-201234.3 KiB

dist-check.mk03-Sep-20124.3 KiB

doc/03-Aug-20144 KiB

gl/20-Sep-20124 KiB

gnulib/05-Mar-20124 KiB

gnulib-tests/05-Mar-20124 KiB

HACKING27-Jun-201423.4 KiB

init.cfg03-Aug-201418.6 KiB

lib/05-Jan-20144 KiB

m4/23-Jan-20144 KiB

Makefile.am15-Jul-20147.4 KiB

man/19-Jul-20144 KiB

NEWS03-Aug-2014174.3 KiB

old/05-Mar-20124 KiB

po/15-Jul-20144 KiB

README15-Jul-201411 KiB

README-hacking05-Jan-20144 KiB

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

README-prereq17-Oct-20132.2 KiB

README-release25-Mar-20134.4 KiB

README-valgrind05-Jan-20141.8 KiB

scripts/05-May-20144 KiB

src/13-Aug-20144 KiB

tests/15-Jul-20144 KiB

thanks-gen05-Mar-2012441

THANKS.in13-Aug-201436.9 KiB

THANKStt.in05-Mar-2012121

TODO05-Jan-20146.8 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 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
89There is a new, implicit build requirement:
90To build the coreutils from source, you should 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.
95If that happens, simply[*] apply the included patch using the following
96command, and then run make again:
97
98  cd src && patch < c99-to-c89.diff
99
100[*] however, as of coreutils-7.1, the "c99-to-c89.diff" file is no longer
101maintained, so even if the patches still apply, the result will be an
102incomplete conversion.  It's been 10 years.  Get a decent compiler! ;-)
103
104
105***********************
106HPUX 11.x build failure
107-----------------------
108
109A known problem exists when compiling on HPUX on both hppa and ia64
110in 64-bit mode (i.e. +DD64) on HP-UX 11.0, 11.11, and 11.23.  This
111is not due to a bug in the package but instead due to a bug in the
112system header file which breaks things in 64-bit mode.  The default
113compilation mode is 32-bit and the software compiles fine using the
114default mode.  To build this software in 64-bit mode you will need
115to fix the system /usr/include/inttypes.h header file.  After
116correcting that file the software also compiles fine in 64-bit mode.
117Here is one possible patch to correct the problem:
118
119--- /usr/include/inttypes.h.orig	Thu May 30 01:00:00 1996
120+++ /usr/include/inttypes.h	Sun Mar 23 00:20:36 2003
121@@ -489 +489 @@
122-#ifndef __STDC_32_MODE__
123+#ifndef __LP64__
124
125
126************************
127OSF/1 4.0d build failure
128------------------------
129
130If you use /usr/bin/make on an OSF/1 4.0d system, it will fail due
131to the presence of the "[" target.  That version of make appears to
132treat "[" as some syntax relating to locks.  To work around that,
133the best solution is to use GNU make.  Otherwise, simply remove
134all mention of "[$(EXEEXT)" from src/Makefile.
135
136
137*************************************************
138"make check" failure on IRIX 6.5 and Solaris <= 9
139-------------------------------------------------
140
141Using the vendor make program to run "make check" fails on these two systems.
142If you want to run all of the tests there, use GNU make.
143
144
145
146**********************
147Running tests as root:
148----------------------
149
150If you run the tests as root, note that a few of them create files
151and/or run programs as a non-root user, 'nobody' by default.
152If you want to use some other non-root username, specify it via
153the NON_ROOT_USERNAME environment variable.  Depending on the
154permissions with which the working directories have been created,
155using 'nobody' may fail, because that user won't have the required
156read and write access to the build and test directories.
157I find that it is best to unpack and build as a non-privileged
158user, and then to run the following command as that user in order
159to run the privilege-requiring tests:
160
161  sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root
162
163If you can run the tests as root, please do so and report any
164problems.  We get much less test coverage in that mode, and it's
165arguably more important that these tools work well when run by
166root than when run by less privileged users.
167
168
169***************
170Reporting bugs:
171---------------
172
173IMPORTANT: if you take the time to report a test failure,
174please be sure to include the output of running 'make check'
175in verbose mode for each failing test.  For example,
176if the test that fails is tests/df/df-P.sh, then you would
177run this command:
178
179  make check TESTS=tests/df/df-P.sh VERBOSE=yes SUBDIRS=. >> log 2>&1
180
181For some tests, you can get even more detail by adding DEBUG=yes.
182Then include the contents of the file 'log' in your bug report.
183
184Send bug reports, questions, comments, etc. to bug-coreutils@gnu.org.
185If you would like to suggest a patch, see the files README-hacking
186and HACKING for tips.
187
188***************************************
189
190There are many tests, but nowhere near as many as we need.
191Additions and corrections are very welcome.
192
193If you see a problem that you've already reported, feel free to re-report
194it -- it won't bother me to get a reminder.  Besides, the more messages I
195get regarding a particular problem the sooner it'll be fixed -- usually.
196If you sent a complete patch and, after a couple weeks you haven't
197received any acknowledgement, please ping us.  A complete patch includes
198a well-written ChangeLog entry, unified (diff -u format) diffs relative
199to the most recent test release (or, better, relative to the latest
200sources in the public repository), an explanation for why the patch is
201necessary or useful, and if at all possible, enough information to
202reproduce whatever problem prompted it.  Plus, you'll earn lots of
203karma if you include a test case to exercise any bug(s) you fix.
204Here are instructions for checking out the latest development sources:
205
206  http://savannah.gnu.org/git/?group=coreutils
207
208If your patch adds a new feature, please try to get some sort of consensus
209that it is a worthwhile change.  One way to do that is to send mail to
210coreutils@gnu.org including as much description and justification
211as you can.  Based on the feedback that generates, you may be able to
212convince us that it's worth adding.  Please also consult the list of
213previously discussed but ultimately rejected feature requests at:
214http://www.gnu.org/software/coreutils/rejected_requests.html
215
216
217WARNING:  Now that we use the ./bootstrap script, you should not run
218autoreconf manually.  Doing that will overwrite essential source files
219with older versions, which may make the package unbuildable or introduce
220subtle bugs.
221
222
223WARNING:  If you modify files like configure.in, m4/*.m4, aclocal.m4,
224or any Makefile.am, then don't be surprised if what gets regenerated no
225longer works.  To make things work, you'll have to be using appropriate
226versions of the tools listed in bootstrap.conf's buildreq string.
227
228All of these programs except 'test' recognize the '--version' option.
229When reporting bugs, please include in the subject line both the package
230name/version and the name of the program for which you found a problem.
231
232For general documentation on the coding and usage standards
233this distribution follows, see the GNU Coding Standards,
234http://www.gnu.org/prep/standards_toc.html.
235
236For any copyright year range specified as YYYY-ZZZZ in this package
237note that the range specifies every single year in that closed interval.
238
239Mail suggestions and bug reports for these programs to
240the address on the last line of --help output.
241
242
243========================================================================
244
245Copyright (C) 1998-2014 Free Software Foundation, Inc.
246
247Permission is granted to copy, distribute and/or modify this document
248under the terms of the GNU Free Documentation License, Version 1.3 or
249any later version published by the Free Software Foundation; with no
250Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
251Texts.  A copy of the license is included in the "GNU Free
252Documentation License" file as part of this distribution.
253

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-2014 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, or with the latest
29  upstream include/uapi/linux/magic.h made available at src/fs-latest-magic.h
30
31    make src/fs-magic-compare
32
33  If it reports new file system magic numbers, add them to src/stat.c.
34  If it is a remote file system, add the new S_MAGIC_* name you created
35  in stat.c to the list of remote file system types in src/tail.c's
36  fremote function.
37
38* Pre-release testing:
39
40  Run the following on at least one SELinux-enabled (enforcing) and
41  one non-SELinux system:
42
43    n=$(( ($(nproc) + 1) / 2 ))
44    sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k -j$(nproc) check-root\
45      && make distcheck \
46      && make -j$n check RUN_VERY_EXPENSIVE_TESTS=yes RUN_EXPENSIVE_TESTS=yes
47
48  If testing on systems with a non standard default shell, spurious failures
49  may occur.  Often there are other shells available, and you can select
50  those by using for example, SHELL=bash in the commands above.
51
52  Note that the use of -j$n tells make to use approximately half of the
53  available processing units.  If you use -jN, for larger N, some of the
54  expensive tests are likely to interfere with concurrent performance-measuring
55  or timing-sensitive tests, resulting in spurious failures.
56
57  If "make distcheck" doesn't run "make syntax-check" for you, then run
58  it manually:
59
60    make syntax-check
61
62* Set the date, version number, and release type [stable/alpha/beta] on
63  line 3 of NEWS, commit that, and tag the release by running e.g.,
64
65    build-aux/do-release-commit-and-tag X.Y stable
66
67* Run the following to create release tarballs.  Your choice selects the
68  corresponding upload-to destination in the emitted gnupload command.
69  The different destinations are specified in cfg.mk.  See the definitions
70  of gnu_ftp_host-{alpha,beta,stable}.
71
72    # "TYPE" must be stable, beta or alpha
73    make TYPE
74
75* Test the tarball.  copy it to a few odd-ball systems and ensure that
76  it builds and passes all tests.
77
78* While that's happening, write the release announcement that you will
79  soon post.  Start with the template, $HOME/announce-coreutils-X.Y
80  that was just created by that "make" command.
81
82Once all the builds and tests have passed,
83
84* Run the gnupload command that was suggested by your "make stable" run above.
85
86* Wait a few minutes (maybe up to 30?) and then use the release URLs to
87  download all tarball/signature pairs and use gpg --verify to ensure
88  that they're all valid.
89
90* Push the NEWS-updating changes and the new tag:
91
92    v=$(cat .prev-version)
93    git push origin master tag v$v
94
95* Announce it on Savannah first, so you can include the preferable
96  savannah.org announcement link in the email message.
97
98  From here:
99    https://savannah.gnu.org/projects/coreutils/
100  click on the "submit news", then write something like the following:
101  (If there is no such button, then enable "News" for the project via
102   the Main -> "Select Features" menu item, or via this link:
103   https://savannah.gnu.org/project/admin/editgroupfeatures.php?group=coreutils)
104
105    Subject: coreutils-X.Y released [stable]
106    +verbatim+
107    ...paste the announcement here...
108    -verbatim-
109
110  Then go here to approve it:
111    https://savannah.gnu.org/news/approve.php?group=coreutils
112
113* Send the announcement email message.
114
115* Approve the announcement here:
116  http://lists.gnu.org/mailman/admindb/coreutils-announce
117
118* After each non-alpha release, update the on-line manual accessible via
119
120    http://www.gnu.org/software/coreutils/manual/
121
122  by running this:
123
124    build-aux/gnu-web-doc-update
125

README-valgrind

1#! /bin/bash
2# Convert this package for use with valgrind.
3
4# Copyright (C) 2002-2014 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