Re: [cp v5.97] --noreply erroneously depreciated

[Chris Velevitch]

On Dec 21, 2007 4:56 PM, Brian Dessent <address@hidden> wrote:
> Chris Velevitch wrote:
>
> > I thought rsync is meant for copying files between machines? In what
>
> There's no requirement that rsync can only be used between two different
> machines.

Then why use rsync locally and not cp?

> > It did have it,
> > until it got depreciated.
>
> No, it didn't have such an option.  Go read those old threads.

Brain, I'm referring to the cp command, but it sounds like cp and mv
use the same mechanism and that threads you are referring to only
talked mv and --reply whereas I searched for cp and --reply.

> --reply=no would *only* have worked in those situations where mv would
> have prompted the user.  That means when -i was also specified and when
> stdout was a terminal.  But for example if -i wasn't given or mv was
> used in a batch/cron situation with stdout redirected it would *not*
> have prompted, and thus the file would be overwritten despite the user
> giving --reply=no.  This was the source of much confusion and the reason
> why it the option was deprecated, because it did work in the manner that
> people expected.

I think I understand the issue.

The way I understand it, the command has 2 different behaviours that
depends on if it's being run in 'batch mode' or 'interactive mode',
'batch mode' being the case where stdout is redirected and
'interactive mode' where stdout is not redirected. But the problem has
arisen because of a third implied mode, 'quasi-batch' mode.
'quasi-batch' mode is when a script is is being run in 'interactive
mode', but the author's intention is that it behaves as if it's
running in 'batch mode'.

The author of a script would test it interactively and discover that
it wants to interact with them because there exists a file of the same
name in the destination. So, they put in options that suppresses the
interaction and to get the desired effect. In this case the desired
effect is to unconditionally keep the existing file. However these
options are only 'interactive mode' options and understandably only
make sense and only work in 'interactive mode'. There are no 'batch
mode' option to unconditionally keep the existing file in the
destination. So when the script is really run in 'batch mode' it fails
to work the way the author intended it to work because of the missing
'batch mode' functionality.

I think the confusion really arises from the fact that there is
functionally that only exists in 'interactive mode' when it should
have existed in both modes. As as result of depreciating the
functionality, any old scripts relying on it are now broken.


Chris
-- 
Chris Velevitch
Manager - Sydney Flash Platform Developers Group
m: 0415 469 095
www.flashdev.org.au