[Top][All Lists]

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

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

From: Andreas 'ads' Scherbaum
Subject: Re: Bug#160849: coreutils: bug report for GNU Core Utils
Date: Fri, 24 Jun 2005 20:15:36 +0200 (CEST)

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.

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.


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

reply via email to

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