Date: Thu, 7 Mar 2002 19:50:03 -0800 (PST) From: swear@blarg.net (Gary W. Swearingen) To: freebsd-doc@freebsd.org Subject: Re: docs/35646: cp(1) page needs a "Bugs" section. Message-ID: <200203080350.g283o3p93086@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/35646; it has been noted by GNATS. From: swear@blarg.net (Gary W. Swearingen) To: Giorgos Keramidas <keramida@freebsd.org> Cc: bug-followup@freebsd.org Subject: Re: docs/35646: cp(1) page needs a "Bugs" section. Date: 07 Mar 2002 19:43:33 -0800 Giorgos Keramidas <keramida@freebsd.org> writes: > Are you sure this should be documented in the manual page of cp(1) ? > Any program that copies data and doesn't take special care of 'holes' will > show similar behavior. Should we modify their manual pages too? > > [ See what dd(1) does instead of cp(1) below. ] [snip...] > Note that I'm not opposing the change. I'm only asking for ideas about all the > possible programs that will behave exactly like cp(1) and dd(1) do, when they > find files with 'holes'. You're clever to think of such things. If the OS could always hide the fact that it was compressing or uncompressing files like this, then it would never need mentioning outside the filesytem documenation. But it doesn't. A user of "cp" or "dd" should be able to predict, based on his reading of the man page or maybe some handbook, whether his use of the command will over-fill his filesystem. Currently, he must resort to trail and error, a method dear to many UNIX users, but not to many others. (Of course, many will not read about it until being bitten.) Such knowledge probably should also be available to users of ">", "|", "cat", and probably some others. Probably less important for "vi", "sed", "awk", because few have expectations as to the size of their outputs. It's going to go undocumented in many cases, but I think "cp" and "dd" are special cases as one often cares much about their outputs. One expects a copy to be identical to the original for all purposes, not just most purposes. I've seen the issue discussed before and it would have been nice to be able to point to documentation on it. But then, I didn't provide such documentation... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203080350.g283o3p93086>