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)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
