конвертировать и копировать файл (convert and copy a file)
Обоснование (Rationale)
The OPTIONS section is listed as ``None'' because there are no
options recognized by historical dd utilities. Certainly, many of
the operands could have been designed to use the Utility Syntax
Guidelines, which would have resulted in the classic hyphenated
option letters. In this version of this volume of POSIX.1‐2017,
dd retains its curious JCL-like syntax due to the large number of
applications that depend on the historical implementation.
A suggested implementation technique for conv=noerror,sync is to
zero (or <space>-fill, if blocking or unblocking) the input
buffer before each read and to write the contents of the input
buffer to the output even after an error. In this manner, any
data transferred to the input buffer before the error was
detected is preserved. Another point is that a failed read on a
regular file or a disk generally does not increment the file
offset, and dd must then seek past the block on which the error
occurred; otherwise, the input error occurs repetitively. When
the input is a magnetic tape, however, the tape normally has
passed the block containing the error when the error is reported,
and thus no seek is necessary.
The default ibs= and obs= sizes are specified as 512 bytes
because there are historical (largely portable) scripts that
assume these values. If they were left unspecified, unusual
results could occur if an implementation chose an odd block size.
Historical implementations of dd used creat() when processing
of=file. This makes the seek= operand unusable except on special
files. The conv=notrunc feature was added because more recent
BSD-based implementations use open() (without O_TRUNC) instead of
creat(), but they fail to delete output file contents after the
data copied.
The w multiplier (historically meaning word), is used in System V
to mean 2 and in 4.2 BSD to mean 4. Since word is inherently non-
portable, its use is not supported by this volume of
POSIX.1‐2017.
Standard EBCDIC does not have the characters '[' and ']'. The
values used in the table are taken from a common print train that
does contain them. Other than those characters, the print train
values are not filled in, but appear to provide some of the
motivation for the historical choice of translations reflected
here.
The Standard EBCDIC table provides a 1:1 translation for all 256
bytes.
The IBM EBCDIC table does not provide such a translation. The
marked cells in the tables differ in such a way that:
1. EBCDIC 0112 ('¢') and 0152 (broken pipe) do not appear in the
table.
2. EBCDIC 0137 ('¬') translates to/from ASCII 0236 ('^'). In
the standard table, EBCDIC 0232 (no graphic) is used.
3. EBCDIC 0241 ('~') translates to/from ASCII 0176 ('~'). In
the standard table, EBCDIC 0137 ('¬') is used.
4. 0255 ('[') and 0275 (']') appear twice, once in the same
place as for the standard table and once in place of 0112
('¢') and 0241 ('~').
In net result:
EBCDIC 0275 (']') displaced EBCDIC 0241 ('~') in cell
0345.
That displaced EBCDIC 0137 ('¬') in cell 0176.
That displaced EBCDIC 0232 (no graphic) in cell 0136.
That replaced EBCDIC 0152 (broken pipe) in cell 0313.
EBCDIC 0255 ('[') replaced EBCDIC 0112 ('¢').
This translation, however, reflects historical practice that
(ASCII) '~' and '¬' were often mapped to each other, as were '['
and '¢'; and ']' and (EBCDIC) '~'.
The cbs operand is required if any of the ascii, ebcdic, or ibm
operands are specified. For the ascii operand, the input is
handled as described for the unblock operand except that
characters are converted to ASCII before the trailing <space>
characters are deleted. For the ebcdic and ibm operands, the
input is handled as described for the block operand except that
the characters are converted to EBCDIC or IBM EBCDIC after the
trailing <space> characters are added.
The block and unblock keywords are from historical BSD practice.
The consistent use of the word record in standard error messages
matches most historical practice. An earlier version of System V
used block, but this has been updated in more recent releases.
Early proposals only allowed two numbers separated by x to be
used in a product when specifying bs=, cbs=, ibs=, and obs=
sizes. This was changed to reflect the historical practice of
allowing multiple numbers in the product as provided by Version 7
and all releases of System V and BSD.
A change to the swab conversion is required to match historical
practice and is the result of IEEE PASC Interpretations 1003.2
#03 and #04, submitted for the ISO POSIX‐2:1993 standard.
A change to the handling of SIGINT is required to match
historical practice and is the result of IEEE PASC Interpretation
1003.2 #06 submitted for the ISO POSIX‐2:1993 standard.
