src-test/bin, branch release/5.2.0

Fix up sh(1) for the release.

2003-12-07T04:03:59Z

This commit was manufactured by cvs2svn to create branch 'RELENG_5_2'.

2003-12-07T03:02:28Z

Do something sensible if both -h and -k are given.

2003-12-01T19:10:29Z

Approved by: re(scottl)

Force a staticly linked /bin and /sbin for ia64. The necessary changes

2003-11-19T16:59:00Z

to gcc have not been made for ia64, which means that executables still have /usr/libexec/ld-elf.so.1 as the dynamic linker. This simply does not work if /usr is a seperate filesystem not mounted when the kernel tries to execute init(8). Note that this is a temporary fix until a new gcc has been imported that does have the required changes. Approved: re@

Change the default for binaries in /bin and /sbin from statically to

2003-11-16T04:57:28Z

dynamically linked. This has been a long time coming with the move of critical libraries from /usr/lib to /lib. If you don't feel comfortable with dynamically linked binaries in your root partition, now is the time to define NO_DYNAMICROOT in your make.conf. Approved by: re

Don't mmap(2) and munmap(2) zero-length files.

2003-11-13T05:26:55Z

Submitted by: Wiktor Niesiobedzki

Fix format strings (intmax_t is %jd, not %qd)

2003-11-12T21:47:42Z

Reviewed by: tjr

Update the statfs structure with 64-bit fields to allow

2003-11-12T08:01:40Z

accurate reporting of multi-terabyte filesystem sizes. You should build and boot a new kernel BEFORE doing a `make world' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. Reviewed by: Bruce Evans Reviewed by: Tim Robbins Reviewed by: Julian Elischer Reviewed by: the hoards of Sponsored by: DARPA & NAI Labs.

When the P flag is set (i.e. Overwrite regular files before deleting them),

2003-11-10T09:40:18Z

do only unlink the file if we could indeed overwrite the file. Old behaviour: rm -P /tmp/foo (foo mode 0444) would NOT overwrite foo, but still delete it (with a warning: rm: foo: Permission denied) New behaviour: Just the EPERM warning, but no deletion Reviewed by: bde

1. Fixed leakage of a file descriptor for every non-fatal failure in

2003-11-08T09:55:16Z

rm_overwrite() (for rm -P). 2. Print the file name in the error message for (fatal) malloc() failures in rm_overwrite(). I first thought that malloc() failures should be non-fatal since they don't prevent proceeding the the next file, but making them non-fatal would normally give too much output for rm -Pr on a large tree in the unlikely event that even one occurs, since the malloc()ed amounts are usually the same. Just print the file name since the malloc()ed amounts are not always the same and it doesn't hurt to know where rm was when it quit. Submitted by: guido ((1) and original version of (2))