what I was trying to do work much better (ie at all. I could have sworn
it was working...) Fix a SEEK_SET to be SEEK_CUR, and make Bruce's
lseek() test work correctly.
useful as a seeking-tool as well as its many other uses. Previously,
dd(1) would succeed with count=0, but wouldn't get to the point that
blocks were to be read/written. This is a more useful behavior, and
this specific case doesn't seem to be handled by POSIX.
commit and those which cause ugly nroff output have been fixed, since
the purpose of the style guideline which they contravene is to reduce
the sizes of deltas.
Reported by: bde
rm must not use FTS_NOCHDIR, since chdir'ing is required for removing
deep directory trees and the ability to remove such trees is required
by POSIX.2 and POLA. The breakage didn't make much difference until
recently, since fts(3) didn't work in deep directory trees. It isn't
clear whether using FTS_NOCHDIR ever fixed anything (Net/2's rm.c is
similar to Lite1's). Perhaps it was actually to limit the damage
caused by the fts bug.
BDEification process of dd(1). Most of the changes are from BDE's archive.
Support for negative offsets is gone again, but the case where you
lseek() onto byte -1 of something from a negative offset using seek/skip
is fixed; if you end up on -1, you won't get a false positive lseek failure.
The biggest changes are to data types (more size_t, for instance) and
argument parsing. skip/seek on /dev/{,k}mem now occurs (instead of "read
until you reach the offset") due to mem devices now being D_DISK. Some
const things are now correctly declared as such, and the "case table"
building is better. The only thing that seems to be left to make dd(1)
everything TOG wants it to be is l10n.
* Consistently misspell built-in as builtin.
* Add a builtin(1) manpage and create builtin(1) MLINKS for all shell
builtin commands for which no standalone utility exists. These MLINKS
replace those that were created for csh(1).
* Add appropriate xrefs for builtin(1) to the csh(1) and sh(1) manpages,
as well as to the manpages of standalone utilities which are supported
as shell builtin commands in at least one of the shells. In such
manpages, explain that similar functionality may be provided as a
shell builtin command.
* Improve sh(1)'s description of the cd builtin command. Csh(1) already
describes it adequately. Replace the cd(1) manpage with a builtin(1)
MLINKS link.
* Clean up some mdoc problems: use Xr instead of literal "foo(n)"; use
Ic instead of Xr for shell builtin commands.
* Undo English contractions.
Reviewed by: mpp, rgrimes
Fix grammar and spelling nits.
Use .Dq and .Qq where appropriate.
Divorce trailing punctuation from quoted elements.
Use .Dq instead of .Xr for builtins.
Remove trailing whitespace and blank lines.
PR: 13340
`opaque', fix reversed description of `nodump', and don't use
`nodump' as an example of adding a `no' prefix since the double
negative would be confusing (it's still confusing -- the implicitly
documented `nonodump' flag doesn't exist).)
To quote their ls(1) specification:
-n
The same as -l, except that the owner's UID and GID numbers are
written, rather than the associated character strings.
Reviewed by: green
Use an upward approximation of the number of characters required
for decimal representations of uid_t, gid_t and u_quad_t, intead
of arbitrary values that may not be safe in the future.
Fix disordering.
Requested by: bde
supposedly it's ksh-derived, and it's not broken in pdksh. I've added
a test for test running as root: if testing for -x, the file must be
mode & 0111 to get "success", rather than just existant.
Reviewed by: chris
significantly easier to read and extend and offers a few new tests.
A few style changes taken from style(9) and OpenBSD, as well as
whitespace cleanups.
This change was discussed on freebsd-committers and freebsd-hackers
and met with approval from at least des, eivind and brian.
PR: 13091
Obtained from: NetBSD
in a long (-l) listing.
MFC-jockies should make sure that bde's concerns regarding the number
of digits required to represent a uid_t and the use of snprintf
on the associated PR have been addressed before going wild.
PR: 12866
Reported by: Philip Kizer <pckizer@nostrum.com>
Obtained from: NetBSD
