> If I may, I would like to suggest a new option for the cp program. Thanks for the suggestions. They are always welcome.
> It would be useful to myself and possibly others if there was an > option to limit the speed at which cp copies a file - for network > use. I quite often copy files via a network, and in particular, the > Windows box doesn't like it that much. Also, the user of that > computer complains about massive slowdowns (typical Windows). You should check out the rsync program. Rsync is a very feature rich copy program. The cp program is meant to be simple, direct, and fast file copy program. The rsync program is specificially designed to provide a plethora of features. It comes from the same folks that brought you Samba and is a great program. http://rsync.samba.org/ rsync --help [...] --bwlimit=KBPS limit I/O bandwidth, KBytes per second You mentioned MS-Windows as well. The GNU team typically does not use nor have access to MS-Windows boxes. But the great folks at Cygwin have taken on the task of developing the Cygwin Toolset which feature porting many parts of the GNU operating system to MS. http://www.cygwin.com > And I might add a little twist to this. I'm only relatively new to > Linux (about 6 months I've been using) and I'm impressed: more than > impressed. As a matter of fact, I'm migrating everything to Linux > now, and trying to do as little as possible on my Windows box. What > I'm getting at is that I'd like to have a crack at programming this > feature. I am very familiar with C++ programming, and also Win32 API > programming (before I saw the light...). I think I might well stuff > it up, or do a bad job, or something like that. But I'd like to have > a go; I wish to start giving back to the GNU/Linux > community. They've given me so much in such a short time; for that, > I wish to help build that community as much as I can. That is, with > the permission of the authors. I suppose they should know when > someone's about to take a hammer to their work... Code submissions are always great. Please submit them as unified diff patches against the latest testing bits available. However many times things that seem like great ideas to the submitter may not seem like such a great thing to the maintainers. The direction and architecture of the program may be in one direction and your submission may be pointing in another. Many times what really should happen is not a modification to an existing program but a whole new program instead. Using 'cp' as one example, 'rsync' with its extensive feature additions is really better of as a separate program. Therefore discussing your ideas first on the mailling lists is recommended. The discussion usually creates a better result. Also, documentation is always a place that needs improvement. Most of the documentation available is in the form of syntax reference manuals which are dry and don't convey the overall how to use the program. The user manuals are frequently a place that needs improvement. And don't overlook other GNU projects and other free software projects. There are many and any one of them might be the one that clicks and can benefit from the help of contributors. Bob _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
