bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: heres my contribution to cp


From: Bob Proulx
Subject: Re: heres my contribution to cp
Date: Wed, 10 Jul 2002 23:51:52 -0600
User-agent: Mutt/1.4i

> This is no bug, but I added a feature to cp that lets us see the speed,
> eta, etc during long or slow network (or tape device) copies.

That is great.  The list is for discussion of the programs as well as
for bugs.

> It is my first attempt to contribute to an open source project so I hope
> it is useful and appreciated and I will do it more.
> 
> Sometimes when I am copying movies over ethernet (especially 10Mbps) I
> dont know if the server is down or crashed, I dont like to stare at a
> blank screen, and I do like to keep an idea of what speeds we are
> getting on the lan.

Don't let me discourage you.  I am on the opposite side of the issue.
But I think it is awesome that you are doing this.

I must ask, are you aware of the 'rsync' program.  It would seem to me
that 'rsync --progress sourcefile destinationfile' would be what you
are looking for.  Also 'rsync --stats'.

Note that IMNHO the coreutils should be lean, mean machines.  I
suggest resisting putting the kitchen sink into them.  Creeping
featurism is a trap.  Programs like rsync have the kitchen sink in
them and it has both good and bad points.

On the OpenSSH list the debate has raged off and on as to what purpose
having 'scp' as well as 'rsync' as different programs serve.  The
answer has always ended up being that people think rsync has too many
features, is way too heavy, and that there is a need for a simple
direct file copy program like scp.  Therefore even though rsync exists
they still ship scp as part of ssh.  I believe that same logic applies
here too.

> I have patched it against the fileutils 4.1 source, and uses the -o flag
> to turn it on.  It is available here:
> 
> http://cratos.ath.cx/~kza/cp.patch

Good stuff.

> I still have these things to do:
> 1. Similar mod to mv
> 2. Relevant man page changes
> 3. Must set up a signal handler that traps a kill or term and turns the
> cursor back on.

Why turn the cursor off?  This seems dangerous since even if you trap
things it is possible for the cursor not to get reset.  Imagine this,
I ssh from one machine to another.  On the remote machine I run the
program which turns the cursor off.  The network connection drops out
between me and the remote machine, which means your trap handler has
no chance of running.  I am now left without a cursor.  Things like
that tend to cause endless trouble for users.

> 4. Find a better format for output display, or possibly let the use
> supply a format string.
> 
> I also have these questions:
> 
> 1. How likely is it that this patch makes it in?
> 2. Should I patch this against 4.1 or 4.1.9?
> 3. What stupid things have I done, done wrong, or neglected to do?
> 4. Anyone have ideas for improvements?

I will debate that cp, mv, etc. should be kept lean and mean.  Note
that I did not try out the patch, I just browsed it causually.  I
would like to see how this is similar or different from rsync
features.  And actually rsync has been a little volatile lately on the
progress stats portion of the program and could use some tweaks and
improvements there itself.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]