docs/177429: dd(1) man page is unclear about semantics of conv=sync

[Ronald F. Guilmette]

The following reply was made to PR docs/177429; it has been noted by GNATS.

From: "Ronald F. Guilmette" <rfg at tristatelogic.com>
To: Peter Pentchev <roam at ringlet.net>
Cc: bug-followup at FreeBSD.org
Subject: Re: docs/177429: dd(1) man page is unclear about semantics of conv=sync
Date: Fri, 29 Mar 2013 13:56:51 -0700

 In message <20130329131835.GA15952 at straylight.m.ringlet.net>, you wrote:
 
 >On Wed, Mar 27, 2013 at 08:21:11PM -0700, Ronald F.Guilmette wrote:
 >>=20
 >> >Number:         177429
 >> >Category:       docs
 >> >Synopsis:       dd(1) man page is unclear about semantics of conv=3Dsync
 >[snip]
 >> >Description:
 >>=20
 >> The man page for dd(1) describes the "sync" parameter of the "conv=3D" op=
 >tion
 >> thusly:
 >>=20
 >>               sync     Pad every input block to the input buffer size.  S=
 >paces
 >>                        are used for pad bytes if a block oriented convers=
 >ion
 >>                        value is specified, otherwise NUL bytes are used.
 >>=20
 >> This verbage is entirely unclear. What is a "block oriented conversion va=
 >lue"
 >> and how would a user know whether or not he had specified one?
 >>=20
 >> The man page should make this more clear & explicit.
 >
 >Well, the "conversion value" is the set of all parameters that you have
 >supplied to "conv" - you can supply more than one using commas.  And I
 >think that "block-oriented" should mean that some of the things that you
 >have specified say that the output should be in blocks - either that it
 >is in blocks by default (and you have *not* requested unblocking it by
 >using "ascii", "oldascii" or "unblock"), or that you've requested that
 >dd(1) make it into blocks using one of the "block", "ebcdic", "ibm",
 >"oldebcdic" and "oldibm" conversion specifiers.
 >
 >Of course, I could be wrong, but that's how I myself understand the
 >manual page.
 
 Thank you, but I think that the important point here is that the man
 page should be clear about all this, so that people can use the tool
 without guessing as to the semantics, and without having to rely on
 additional sources of information about the semantics (e.g. the source
 code).
 
 
 Regards,
 rfg