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
On Fri, Jun 24, 2005 at 11:17:20AM -0600, you wrote:
The second option that I recommend is to deprecate this option
entirely and remove it from the code base.
I think it's safe to say that a number of these utilities have gotten
more flags than they strictly need. Pruning may be a good thing.
Jim Meyering wrote:
> "Andreas 'ads' Scherbaum" <[EMAIL PROTECTED]> 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
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
> >
Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> writes:
> Is this just the current working or the expected behaviour?
>
> In my opinion the --reply=no would make much more sense if i could use it
> in scripts to avoid overwriting files.
IMHO what you are looking for does not fit into the purpose of
On Fri, 24 Jun 2005, 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
Jim Meyering <[EMAIL PROTECTED]> writes:
> Andreas Schwab <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>> Thanks, but that's not accurate, since --reply=no has no effect
>>> if it *precedes* a -i (aka --reply=query) option, and if it
>>> follows -i, then the -i is disreg
"Andreas 'ads' Scherbaum" <[EMAIL PROTECTED]> wrote:
...
> Is this just the current working or the expected behaviour?
It is the intended behavior.
> In my opinion the --reply=no would make much more sense if i could use it
> in scripts to avoid overwriting files.
>
> To quote the current manpage
On Fri, 24 Jun 2005, Jim Meyering wrote:
Eric Blake <[EMAIL PROTECTED]> wrote:
According to Jim Meyering on 6/24/2005 1:58 AM:
Now, the help output for --reply looks like this:
--reply={yes,no,query} specify how to handle the prompt about an
existing
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> Thanks, but that's not accurate, since --reply=no has no effect
>> if it *precedes* a -i (aka --reply=query) option, and if it
>> follows -i, then the -i is disregarded.
>
> Why not just say that -i/-f/--reply o
Jim Meyering <[EMAIL PROTECTED]> writes:
> Thanks, but that's not accurate, since --reply=no has no effect
> if it *precedes* a -i (aka --reply=query) option, and if it
> follows -i, then the -i is disregarded.
Why not just say that -i/-f/--reply override each other and the last one
wins?
Andrea
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 6/24/2005 1:58 AM:
>> Now, the help output for --reply looks like this:
>>
>> --reply={yes,no,query} specify how to handle the prompt about an
>> existing destination file. Note that
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 6/24/2005 1:58 AM:
> Now, the help output for --reply looks like this:
>
> --reply={yes,no,query} specify how to handle the prompt about an
> existing destination file. Note that
>
"Andreas 'ads' Scherbaum" <[EMAIL PROTECTED]> wrote:
> Package: coreutils
> Version: 5.2.1-2
> Followup-For: Bug #160849
>
> independent from this bugreport (i did not known it), i filed a bug
> report on the GNU core bug page:
>
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=12903
Thanks
Package: coreutils
Version: 5.2.1-2
Followup-For: Bug #160849
independent from this bugreport (i did not known it), i filed a bug
report on the GNU core bug page:
http://savannah.gnu.org/bugs/?func=detailitem&item_id=12903
regards
-- System Information:
Debian Release: 3.1
Architecture: i386
15 matches
Mail list logo
