The signal handler tries to raise the signal again, so that a parent can retrieve
the signal from the exit code. Calling the terminate handler with signal code 0
doesn't raise a signal and dd continues with exit(127) making this case an error.
standardised the table from V7. Nobody, including the original authors,
seems to have noticed this. Merge them and update the documentation.
Also fix the odd, inconsistent, spelling of "pre-4.3BSD-Reno").
(From nabijaczleweli)
No change to the resulting binary. The 'return' statements are necessary
for GCC to generate the exact same object code, even though they can be
removed without affecting the functionality, as seen before the 'else'.
our implementation was fine, but the restrict marker is problematic
as gcc 8 is now more strict about checking for restrict issues.
this is the only actual consumer of swab(3) in our tree, though,
besides the test for it. oh well.
Like GNU dd(1) similar operands, iflag and oflag allow specifying the
O_* flags given to open(2) for the input and the output file. The values
are comma-sepratated, lower-case, O_ prefix-stripped constants documented
in open(2).
Since iflag and oflag override default values, specifying oflag means
O_CREATE is not set by default and must be specified explicitely.
Some values do not make sense (e.g.: iflag=directory) but are still used
and will raise a warning. For oflag, values rdonly, rdwr and wronly are
filtered out with a warning (dd(1) attempts open(2) with O_RDWR and
then O_WRONLY on failure).
Specifying oflag=trunc along with (seek, oseek or conv=notrunc) is
contradictory and will raise an error.
iflag and oflag are disabled if building with -DMALLPROG
- error out when an unknown specifier is used. Do this in f_msgfmt(),
before dd(1) starts operation.
- allow buffer_write() to flush the internal buffer even when NULL is
passed as parameter.
Some whitespace fixes too.
output of the information summary returned by dd(1). This can be used
to specify messages in a more usable (or parseable) format like
human-readable values.
My intent is to re-use this for building image files and quick I/O
benchmarking.
Reviewed by tsutsui@ on tech-userlevel. See also
http://mail-index.netbsd.org/tech-userlevel/2010/12/03/msg004179.html
Some examples:
$ dd if=/dev/zero of=/dev/null bs=1m count=1 msgfmt=human
1+0 records in
1+0 records out
1048576 bytes (1,0 MB) transferred in 0.001 secs (1048576000 bytes/sec - 1,0 GB/sec)
$ dd if=/dev/zero of=/dev/null count=1 msgfmt='
> <speed>%E</speed>
> <time>%s</time>
> <bytes>%b</bytes>
> '
<speed>500 KB/sec</speed>
<time>0.001</time>
<bytes>512</bytes>
"if" and "of" with the exception that the communicate with a rump
kernel instead of the host kernel.
For example, to write stdout to /tmp/file.txt in a rump kernel namespace:
dd rof=/tmp/file.txt
copy /file1 to /file2 inside a rump kernel:
dd rif=/file1 rof=/file2
copy a snippet from /dev/rmd0d on the rump kernel to the host fs:
dd rif=/dev/rmd0d of=save seek=1000 count=3
Eat that, usermode OS.
(I'll document the operands one I have some manpage to refer to
for rump client use).
mlelstv