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

2005-06-24 Thread Michael Stone
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.

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

2005-06-24 Thread Andreas 'ads' Scherbaum
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

Re: SIGSEGV

2005-06-24 Thread Paul Eggert
Geoffrey Buckle <[EMAIL PROTECTED]> writes: > System crashed with the signal 11. Sorry, that's not enough information to reproduce the bug. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

bug in du --time=atime

2005-06-24 Thread Paul Eggert
A problem that I just noticed with the recent change to "du" is that "du --time=atime" always reports the current time, for all entries. This is because du reads each directory first, before it stats it, which means the directory's last-accessed time is always the current time. Can you please look

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

2005-06-24 Thread Bob Proulx
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

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

2005-06-24 Thread Bob Proulx
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 > >

Re: Suggested enhancement to du command - show last modified date.

2005-06-24 Thread Frederik Eaton
This is nice. One reason I like it, which I think hasn't been mentioned yet, is that it gives a standard interface to a piece of information that might be used by make systems and other programs which need to find out when directory trees have been modified. Working through a standard interface mea

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

2005-06-24 Thread Andreas Schwab
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

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

2005-06-24 Thread Andreas 'ads' Scherbaum
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

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

2005-06-24 Thread Andreas 'ads' Scherbaum
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

SIGSEGV

2005-06-24 Thread Geoffrey Buckle
System crashed with the signal 11. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

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

2005-06-24 Thread Andreas Schwab
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

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

2005-06-24 Thread Jim Meyering
"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

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

2005-06-24 Thread Jim Meyering
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

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

2005-06-24 Thread Andreas Schwab
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

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

2005-06-24 Thread Eric Blake
-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 >

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

2005-06-24 Thread Jim Meyering
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 >>

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

2005-06-24 Thread Jim Meyering
"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