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

[Bob Proulx]

Jim Meyering wrote:
> "Andreas 'ads' Scherbaum" <address@hidden> wrote:
> ...
> > Is this just the current working or the expected behaviour?
> 
> It is the intended behavior.

This behavior has confused a number of people so far.  It makes sense
to me because I know how it works.  I can see the state transition
diagram and follow it and mv is just executing it.  It also depends
upon the legacy behavior of mv to prompt if the standard input is a
tty and not prompt if the standard input is not.  That adds another
layer.

> > In my opinion the --reply=no would make much more sense if i could use it
> > in scripts to avoid overwriting files.

The behavior does not support that functionality.  So you can't.
About all you could do in that case is the following.

  yes n | mv -i srcfile dstfile 2>/dev/null

But that has the unfortunate and unwanted effect of discarding errors too.

> > To quote the current manpage:
> >
> >        --reply={yes,no,query}
> >               specify how to handle the prompt about an existing
> >               destination file
> 
> IMHO, the above is not inaccurate -- but it's obviously not clear,
> either :)  It says how to handle a *prompt* about an existing
> destination file.  The prompt in question (not the prompt for -i)
> appears only under the conditions mentioned in my addition.
> It's important to realize that if you specify `-i --reply=no',
> it's equivalent to just `--reply=no', hence there will be no
> prompts due to the `-i' option.  Yes, I admit it is rather twisted.

I believe it creates behavior which is not really useful.  For
example, it allows a user to create an alias or function that always
overwrites files without prompting.  That much is okay.  But that same
behavior could have been created with 'mv -f' too.

It also allows a user to create an alias or function which always
answers no to prompting.  I think that is bad because now whether the
mv actually happens or not is completely silent.  I think this is more
confusing.  For example a script using --reply=no will work one from
from the command line and a different way from a crontab where input
is redirected from /dev/null.

> > This would apply to any existing file, not just for "not writable",
> > "stdin" or a terminal. So the correct bugfix should not a new manpage
> > chapter but instead a improved behaviour of 'mv'.
> 
> IMHO, you're asking for a new feature (don't overwrite any existing
> file and don't prompt about it either).

I think that new feature is exactly what users want.  That is the
feature that would be truly useful.

Let me throw myself on the side that this appeared to be a good
behavior to implement but in practice has turned out to be not a good
thing to do.  I think it is not intuitive and not the right behavior
to implement.  The fact that there has been so much discussion shows
that we have created a complicated implementation and are now trying
to make it right by creatively documenting it.  But most users are not
going to be able to keep the entire flow in their head so even if we
are successful in fully documenting it I don't think that is the right
answer.

Instead of spending the effort to document the behavior I suggest that
one of two actions be taken.  One would be to change the code to
implement different and more desireable behavior.  I understand that
is a lower priority, no one uses these options anyway, and the problem
is a subtle one to fix completely.  So unless someone has time to
spend the effort on this it won't happen anytime soon.  That is okay.

The second option that I recommend is to deprecate this option
entirely and remove it from the code base.  The longer it remains the
harder it will be to change to better behavior later.  It is not
really useful as it stands today.  (I am happy to see challenges to
that last statement.)

Bob

-- 
Any sufficiently advanced bug is indistinguishable from a feature.
                -- Rich Kulawiec