Re: Bug#160849: coreutils: bug report for GNU Core Utils

[Andreas 'ads' Scherbaum]

On Fri, 24 Jun 2005, Bob Proulx wrote:

> Andreas 'ads' Scherbaum wrote:
> > Andreas Schwab wrote:
> > > -f, --force, --reply=yes     do not prompt before overwriting
> > > -i, --interactive, --reply=query
> > >                              prompt before overwrite
> > >     --reply={yes,no,query}   specify how to handle the prompt about an
> > >                                existing destination file
> >                                   ^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > This part is the problem.
> >
> > If i understand Jim correct, its all not about an existing destination
> > file (mv will just overwrite it), but about how to handle the case, if the
> > destination file is not writable:
>
> And there is an additional control lever that your fine example does
> not show.  Let me expand on it and annotate it.

Yes, i accept your example. Mine was only to show, what in my opinion is 
the problem with the documentation example given by Andreas Schwab.
The "reply" option does not really care about an existing file, it needs 
more circumstances to jump in.


> When standard input is not a tty --reply=no can never have any affect
> because 'mv' would never prompt.  Really the --reply=no and
> --reply=yes options are only useful on the command line for
> interactive use.  It gives a way for a user to turn off that question
> and to make 'mv' always overwrite the file.  But the reverse is not
> true.  For that you would need this:
>
>  test -f def || mv abc def
>
> I can't think of any time when the --reply={yes,no,query} options
> would be appropriate for use in a script.  Well, if I stretch I could
> produce this contrived example.  This would avoid overwriting any
> existing files.  (quick hint: 'yes' here is going to print 'n' and
> answer the question forced from mv.)
>
>  touch abc def
>  chmod a-w def
>  yes n | mv --reply=query abc def
>  ls -ldog abc def
>  -rw-r--r--  1 0 2005-06-24 10:22 abc
>  -r--r--r--  1 0 2005-06-24 10:22 def
>
> In which case because --reply is not portable I would use th -i option
> instead.  This is perfectly equivalent but should be portable.

I ran into the problem in a situation where i wanted to move a lot of 
files without overwriting and without questioning me. So no (easy) way to 
test the existence of every target file in every subdirectory.

The reply option seems to perfectly fit in, according to the 
documentation. Without playing around with stdin or pipes or the terminal 
type and without testing the existance of the destination file.



> > This is, what i mentioned before: this parameter does not really what
> > someone would expect.
>
> I tend to agree.  I don't think the behavior is truly useful.

ack.
If i think about it: strong ack.

Live would be more easy, if reply would just do what the current manpage 
promises. This would even include the current behaviour.


Regards

--
                                Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
 (Ferenc Mantfeld)