|
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.
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)
[Prev in Thread] | Current Thread | [Next in Thread] |