>>>>> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
Jim> Thanks for the report.
You're welcome. Thanks for the quick reply. I hope my reply here
doesn't sound too harsh. I'm trying to make it clear why I think the
current situation is more confusing than it appears and I'm also
suggesting how to fix it, although my strongest suggestion is to
replace --reply. I'm not trying to pick nits. With fileutils 4.1.9
if anyone writes
mv --interactive --reply=no file1 file2
file2 will be overwritten if it already exists. I think that's
not only a surprising result, but a surprising result that destroys
unsuspecting people's files without them even knowing about it.
>> So the man page talks about a prompt about an existing
>> destination file, when no such prompt, per-se, will be
>> generated, since you need -i to generate such a prompt. When
>> -i and --reply=no are on the same line, you get the behavior of
>> whichever option appears last (right most).
Jim> Documentation improvements are welcome.
I don't mind writing some improvements, but if there's a chance that
the switches and/or the semantics of the switches can be changed, I'd
like to pursue that, first (more info below).
Jim> FYI, `info mv' does include the following paragraph, at least
Jim> in this release:
Jim> ftp://alpha.gnu.org/gnu/fetish/coreutils-4.5.4.tar.bz2
Jim> (coreutils is the union of fileutils, textutils, and
Jim> sh-utils)
Jim> but that may not be in fileutils-4.1.9.
Jim> If a destination file exists but is normally unwritable,
Jim> standard input is a terminal, and the `-f' or `--force'
Jim> option is not given, `mv' prompts the user for whether to
Jim> replace the file. (You might own the file, or have write
Jim> permission on its directory.) If the response does not begin
Jim> with `y' or `Y', the file is skipped.
It is there, but the man page says "...the prompt about an existing
destination file". There is no singular such prompt. There's a
prompt for when the destination file exists but is normally unwritable
and there's a prompt for then there's an existing destination file
regardless of the permissions. Since the man page only mentions
"an existing destination file", and doesn't say anything about
"normally unwritable", it's easy to think that --reply=no, would be
concerned with the general case of an existing destination file,
rather than the specific case of an existing file that is normally
unwritable.
In fileutils 4.1.9 not only is that not the case, but if you use
--interactive --reply=no, the behavior is to silently overwrite
existing files.
Jim> If you feel like improving the documentation, I'd welcome
Jim> specific suggestions -- especially in the form of patches.
Jim> Otherwise, I'll get to it, eventually.
I think the idea of having a command switch whose name and semantics
are associated with what to do with prompts for certain conditions is
not as good as having command switches that directly address the
conditions. Another example of problems with the current semantics
are what should --reply=no do when a pre-existing destination file
exists, is unwritable, but standard input isn't a tty? If the
the semantics of the --reply switch are defined to be what to do when
there would otherwise be a prompt, then --reply=no should have no
effect in that case, since the prompt wouldn't have been printed.
Unless it's part of POSIX, I'd recommend documenting --reply as going
away and then replace it either with one switch which deals with
overwriting in general and has enough options to cover both
pre-existing and writable and pre-existing and unwritable or two
separate switches, one that covers overwriting in general and the
other which covers overwriting when the file permissions don't allow
writing.
Some examples follow. The names are a bit wordy, but I'd guess these
would be used in shell scripts, so I don't see wordiness a big issue.
I'm more interested in the functionality these would provide (and the
fact that documenting them would be trivial), so if the same
functionality could be provided with smaller (but not misleading)
words, that would be great.
--overwrite={never,writable,query-writable,query-always,always}
or
--overwrite-destination={never,query,always}
and
--overwrite-unwritable-destination={never,query,always}
While I'm suggesting changes, I'll also suggest
--error-exit={never,one-fail,all-fail}
which tells mv to provide an error exit value never, when at least one
of the mvs failed or when all of them did. Then the documentation for
that switch could also mention that the default is never.
Jim> FYI, each man page is generated automatically from the
Jim> corresponding tool's --help output, and as such isn't usually
Jim> as complete as the texinfo documentation.
Right. But even the mv info information defines reply's behavior by
talking about prompts in such a way that I'd think many people would
think that --interactive --reply=no would prevent the overwriting of a
pre-existing destination file.
If it's too late to get rid of --reply, I'll write some more precise
documentation for exactly what it does. I'll have to run a bunch of
test cases, since it's by no means obvious what it should do in a
variety of cases. I'll then either add a usage note that says
something like
--reply is a misnomer because it doesn't really have to do
with replies to prompts; it only deals with the specific
case of pre-existing unwritable files
or I'll add a warning that suggests people never use --reply, because
by being based on replies to prompts, it's exceedingly difficult to
tell what it might do in future versions of mv. I'll also add a check
to mv so that if you combine --interactive with --reply an error is
printed a non-zero error value is returned and mv will do nothing.
Currently, --reply appears to behave as though it really only
addresses overwriting unwritable destination files, regardless of
whether a prompt for such a condition would be printed in the absence
of --reply. Although that case overlaps what the mv documentation
states, it's not equivalent.
--Cliff After their escape, purchases of
[EMAIL PROTECTED] lightweight fabrics were limited
_______________________________________________
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils
