Date: Fri, 29 Aug 2014 03:02:11 -0400 From: Glen Barber <gjb@FreeBSD.org> To: Warner Losh <imp@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r270771 - head/bin/dd Message-ID: <20140829070211.GE1200@hub.FreeBSD.org> In-Reply-To: <20140829135805.E965@besplex.bde.org> References: <201408282130.s7SLUdOq002677@svn.freebsd.org> <20140829135805.E965@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--fOHHtNG4YXGJ0yqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2014 at 03:37:12PM +1000, Bruce Evans wrote: > On Thu, 28 Aug 2014, Warner Losh wrote: >=20 > >Author: imp > >Date: Thu Aug 28 21:30:39 2014 > >New Revision: 270771 > >URL: http://svnweb.freebsd.org/changeset/base/270771 > > > >Log: > > Add canonical population of a disk / thumb drive from an image > > example. > > > >Modified: > > head/bin/dd/dd.1 > > > >Modified: head/bin/dd/dd.1 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >--- head/bin/dd/dd.1 Thu Aug 28 21:27:37 2014 (r270770) > >+++ head/bin/dd/dd.1 Thu Aug 28 21:30:39 2014 (r270771) > >@@ -408,6 +408,11 @@ To create an image of a Mode-1 CD-ROM, w > >for data CD-ROM disks, use a block size of 2048 bytes: > >.Pp > >.Dl "dd if=3D/dev/acd0 of=3Dfilename.iso bs=3D2048" > >+.Pp > >+Write a filesystem image to a memory stick, padding the end with zeros, > >+if necessary, to a 1MiB boundary: > >+.Pp > >+.Dl "dd if=3Dmemstick.img of=3D/dev/da0 bs=3D1m conv=3Dnoerror,sync" > >.Sh SEE ALSO > >.Xr cp 1 , > >.Xr mt 1 , >=20 > dd.1 doesn't use the MiB uglyness anywhere else. It even defines 1M > correctly: >=20 > Where sizes are specified, a decimal, octal, or hexadecimal number of > bytes is expected. If the number ends with a ``b'', ``k'', ``m'', `= `g'', > or ``w'', the number is multiplied by 512, 1024 (1K), 1048576 (1M), > 1073741824 (1G) or the number of bytes in an integer, respectively. = Two > or more numbers may be separated by an ``x'' to indicate a product. >=20 > dd also has the correct amount of support (none) for power of 10 sizes in > args. >=20 > However, it is not useful to use 1M in the description of ``m''. It > basically describes ``m'' by saying that it is ``M''. 1048576 is > sufficient and not mistakable for 1000000. The technical term 1M is > not used anywhere in the man page. Similarly for 1K and 1G. >=20 > However2, dd also accepts upper case aliases for ``m'', etc. These are > relatively recent bugs in FreeBSD. They are too recent for news of them > to have reached the man page. There aren't enough letters to use 2 > aliases every power of 2 size, especially starting some years after the > MiB uglyness. >=20 > humanize_number(3) still have much the same bugs, except it supports > power of 10 sizes. expand_number(3) is a little better. > humanize_number() doesn't humanize numbers. It converts integers into > a string representation in a special dehumanized (scientific) format. > expand_number() doesn't expand numbers. It parses string > representations of integers into object representations of integers. > This is rarely an expansion. Normal English usage is that "12345" > is a decimal expansion of a number, not that the number is an expansion > of "12345". The string representation is usually also larger in size. >=20 > expand_number() documents its wastage of 2 aliases for every power of > 2 size and its null support for power of 10 sizes. It doesn't > explicitly document its null support for suffixes like "MiB". It still > describes the suffixes as prefixes. They may be prefixes in some > technical SI sense, but they are always suffixes for the parser. > (Indeed, they are prefixes in the technical sense of being prefixes > for units. expand_number() only "expands" raw numbers, so the units > are null.) It doesn't document its support for hex and octal numbers. > dd does document this, if not the complete syntax. expand_number() > has some extensions like support for 3 suffixes above g, but doesn't > support multpliers like dd. Otherwise, it parses string representations > of numbers much like dd. >=20 > humanize_number() doesn't waste letters for suffixes. It only prints > upper case suffixes, except k means 1000 and K means 1024 (it has no > support for floating point numbers so it doesn't need lower case > suffixes like m for milli). It has an option to print power of 2 > suffixes in the uglified Mi format. It has an option to print a suffix > like "B", so that megabytes become "MB" or "MiB" or even >=20 > "MB is the correct spelling of 104876 bytes; MiB is ugly, but not > as ugly as mebiB; fortunately, this function cannot print mebi, > since it only prints upper suffixes except for k." >=20 > This explains some of the confusing uses of "prefix". First the digits > representing the number are put in the string. Then an SI suffix is > appended if necessary. Then a suffix like "B" is appended if requested. > So the SI suffixes may be in the middle. expand_number() doesn't > support suffixes like "B". Oops. The suffix is documented as always > being printed, with a space between it and the rest, so "MB" is > impossible. There is an HN_NOSPACE flag for suppressing the space > before the SI suffixes, but I don't see one for the final suffix. > Most callers are like df and space-constrained, so they use HN_NOSPACE > and don't print a "B" suffix. I think they sometimes get the space > before the empty suffix at the end, and either use this as a separator > or do extra work to remove it. There is also an HN_B flag which gives > a suffix in the SI position if the SI suffix is null. Most disk > utilities use this, but only small files end up with a "B" suffix > from this. When they do, the space before it is controlled by HN_NOSPACE. > Parsing "1 M B" and "1 M" would be harder than parsing "1MB" and "1M". > expand_number() supports the "B" suffix with no space before it, as will > occur for small numbers printed using HN_B | HN_NOSPACE, but news of this > has not reached its man page. It has a large incompatibily with dd > here -- "b" and "B" mean 512 in dd. >=20 This might be a bad time to mention it, but the .Dd wasn't bumped for this change. Glen --fOHHtNG4YXGJ0yqR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUACVzAAoJELls3eqvi17QYNIP/R19VEyIeN3xXukwJGMXggJn VDgrL41W02y15wPaAeTqHiwxkqCTBjoImJKjGWUzkOHphCcmLq6OEdN2GgUxd4SW IN7vH83KN73801n4ypzjFA5pfxClwChR+OQ9cWsh+OUfpFc4jcc7BdKfBRC+0ZPh URFTFpWIpH7MOkW9Vc5ZsU21gzzYN5VqQH8Heg5U5TaVLHs8FVUA2CeC+H6sCNrV h2wlDX7jiu7vsn+KcmTpAerG66T+nyF0UgOUBsCDzfZOASTzl0zeus1Fmdzs/KYb Gws+PLKuqKTTbLWvddaXaBPxECS09H9fu6djogrr4jtdTV6IvEkRR+Cy66TA+qxF uYTWZUnkfHOFn2dQaJaeKV9FdqUe/45iL64E8eOi3UcKZOGjIJkLmpo9VG6iX/Pp YZnILicJYZs1xAKHcoiCOOsmPjNGNuTK5mbS3Lu1HgnFuD0jOvAGKPdtXQD0MrVH Rcnd5/Vy9Z+S3YmkGnHSptX0TVnmlMztvz6VKJctZbEAq/xlZq9I2/e/d4WWwFoJ viUeSGw2KSlOeWJsDtDlKMgzTqmsAZ1IXmRR3XtZSkouxkdAXlDE6YcYuPODAE3V xzX340+TLOI9kFFEYMun5TIuHvo3H+H/V24VEXa7y3mEU78r05TODdk9x5P4Xkv7 HpgMVXA3gwx7HKvDWZI5 =Xwfr -----END PGP SIGNATURE----- --fOHHtNG4YXGJ0yqR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140829070211.GE1200>