Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!ulysses!ggs From: ggs@ulysses.homer.nj.att.com (Griff Smith) Newsgroups: comp.unix.wizards Subject: Re: "dd conv=unblock cbs=80 " Summary: It's a long story Message-ID: <10479@ulysses.homer.nj.att.com> Date: 31 Jul 88 02:20:11 GMT References: <144@insyte.UUCP> <3350@phri.UUCP> <8168@ncoast.UUCP> <736@esl.UUCP> Organization: AT&T Bell Laboratories, Murray Hill Lines: 51 In article <736@esl.UUCP>, mac@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@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@ulysses.att.com