NameDateSize

..06-Nov-20134 KiB

.gitattributes05-Mar-2012309

.gitignoreToday3 KiB

.gitmodules05-Mar-201289

.mailmap13-Feb-20151.8 KiB

.prev-version11-Mar-20175

.vg-suppressions03-Jan-20171.9 KiB

.x-update-copyright03-Jan-201554

AUTHORS23-Nov-20163.7 KiB

bootstrap23-Jan-201730.8 KiB

bootstrap.conf13-Mar-20177.2 KiB

build-aux/13-Feb-20174 KiB

cfg.mk29-Mar-201735.6 KiB

configure.ac13-Feb-201721.7 KiB

COPYING05-Mar-201234.3 KiB

dist-check.mk01-Dec-20164.5 KiB

doc/23-Apr-20174 KiB

gl/20-Sep-20124 KiB

gnulib/05-Mar-20124 KiB

gnulib-tests/05-Mar-20124 KiB

HACKING07-Feb-201723.4 KiB

init.cfg07-Apr-201719.8 KiB

lib/03-Jan-20174 KiB

m4/17-Jan-20174 KiB

Makefile.am09-Feb-20177.8 KiB

man/03-Mar-20174 KiB

NEWSToday194.4 KiB

po/19-Feb-20174 KiB

README17-Jan-201710 KiB

README-hacking17-Jan-20173.9 KiB

README-package-renamed-to-coreutils17-Jan-2017544

README-prereq17-Jan-20172.2 KiB

README-release17-Jan-20175 KiB

README-valgrind03-Jan-20171.8 KiB

scripts/19-Nov-20154 KiB

src/Today4 KiB

tests/Today4 KiB

thanks-gen05-Mar-2012441

THANKS.in23-Nov-201637.3 KiB

THANKStt.in05-Mar-2012121

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

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-2017 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 <http://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      <http://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      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  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-2017 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