[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: |
Bob Proulx |
Subject: |
Re: Bug#160849: coreutils: bug report for GNU Core Utils |
Date: |
Fri, 24 Jun 2005 10:53:15 -0600 |
User-agent: |
Mutt/1.5.9i |
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.
> address@hidden:/home/ads > rm -rf abc def
> address@hidden:/home/ads > touch abc def
> address@hidden:/home/ads > ls -ld abc def
> -rw-r--r-- 1 ads ads 0 Jun 24 16:31 abc
> -rw-r--r-- 1 ads ads 0 Jun 24 16:31 def
The test case is initialized. There will be no prompts from 'mv'.
> address@hidden:/home/ads > /bin/mv --reply=no abc def
> address@hidden:/home/ads > ls -ld abc def
> ls: abc: No such file or directory
> -rw-r--r-- 1 ads ads 0 Jun 24 16:31 def
The --reply=no had no effect here whatsoever. 'mv' would not have
prompted. The target existed but was writable.
> address@hidden:/home/ads > rm -rf abc def
> address@hidden:/home/ads > touch abc def
> address@hidden:/home/ads > chmod a-w def
> address@hidden:/home/ads > ls -ld abc def
> -rw-r--r-- 1 ads ads 0 Jun 24 16:32 abc
> -r--r--r-- 1 ads ads 0 Jun 24 16:32 def
The next test case is initialized. This creates a case that 'mv' will
prompt _under certain circumstances_.
> address@hidden:/home/ads > /bin/mv --reply=no abc def
> address@hidden:/home/ads > ls -ld abc def
> -rw-r--r-- 1 ads ads 0 Jun 24 16:32 abc
> -r--r--r-- 1 ads ads 0 Jun 24 16:32 def
To fully understand this it is important to know how 'mv' behaves in
two other cases.
With no options:
/bin/mv abc def
mv: overwrite `def', overriding mode 0444? n # I will answer no here
ls -ldog abc def
-rw-r--r-- 1 0 2005-06-24 09:49 abc
-r--r--r-- 1 0 2005-06-24 09:49 def
When standard input is not a tty.
/bin/mv abc def < /dev/null
ls -ldog abc def
ls: abc: No such file or directory
-rw-r--r-- 1 0 2005-06-24 10:15 def
Because the standard input is not a tty there is no prompting. The
default behavior will be to perform the requested action.
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.
yes n | mv -i 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
> 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.
Bob
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Jim Meyering, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Eric Blake, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Jim Meyering, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Andreas Schwab, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Jim Meyering, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Andreas Schwab, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Andreas 'ads' Scherbaum, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils,
Bob Proulx <=
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Andreas 'ads' Scherbaum, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Andreas 'ads' Scherbaum, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Jim Meyering, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Bob Proulx, 2005/06/24
- Re: Bug#160849: coreutils: bug report for GNU Core Utils, Michael Stone, 2005/06/24
- Deprecating mv's --reply={yes,no,query} option, Jim Meyering, 2005/06/30
- Re: Deprecating mv's --reply={yes,no,query} option, Tim Waugh, 2005/06/30
- Re: Deprecating mv's --reply={yes,no,query} option, Jim Meyering, 2005/06/30
- Re: Deprecating mv's --reply={yes,no,query} option, Tim Waugh, 2005/06/30
- Re: Deprecating mv's --reply={yes,no,query} option, James Youngman, 2005/06/30