"dd conv=unblock cbs=80 "

[Griff Smith]

In article <736 at esl.UUCP>, mac at esl.UUCP writes:
...
>    dd if=/dev/rmt0 ibs=64k cbs=80 conv=unblock ...
> 	... isn't in any ATT man page.
> 
> 	/bin/dd never read the man page, and fully supports the undocumented
>    cbs and conv=unblock/block options.
> 
> -- 
>  Michael Mc Namara                 
>  Cydrome Incorporated                 
>  ARPA: esl!cydrome!mac at ames.arpa    

Not quite true.  I have a fine version of the manual page on my system
at AT&T.  It's the same one I sent to Summit a few years ago, along
with the SVr3 re-write of dd.  That was the end of a long story that
started about 1984 when I looked at the source code for dd and realized
that the EBCDIC -> ASCII conversion option was painfully inefficient,
which caused some of our production tape jobs to take hours of CPU
time.  Over a weekend, I wrote most of the code for a version that was
5 to 10 times faster than the one they distributed.  After proving my
point to my supervisor, I finished the job (I also neglected to
re-implement 9 bugs in the process).  Then I tried to contribute it to
the Unix System development people.  I was formally ignored, and
informally told that dd was such an unimportant program that it wasn't
worth the resources required to do new design specifications, code
reviews, etc.  A few years later, some winds of change finally blew
through Summit and my re-write was quietly substituted for the broken
version in the 3.0 release.  A few months later, I looked at the shiney
new System V manuals for the revised documentation and was concerned to
see that the BSD features that I had added were not mentioned.  A check
of the code confirmed that my code had not been changed, but I realized
that I had a new problem; if I reported the inconsistency between the
code and the documentation the support people would have two choices:

1) update the documentation

2) strip the new features to make the code match the documentation

After two years of aggravation, I didn't have the strength to go
through it again.  I decided to wait until lots of people had
discovered the new features, which would make option (2) a public
relations disaster.  I think it's safe to send them the manual pages
now.  Sorry to be so devious, but this place was really strange a few
years ago.  My thanks to the people at Summit (especially to the
ToolChest maintainers) who passed me suggestions for doing end-runs
around the bureaucracy.
-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{allegra|ihnp4}!ulysses!ggs
Internet:	ggs at ulysses.att.com