bug-coreutils
[Top][All Lists]
Advanced

[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




reply via email to

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