bug#18103: sleep infinity
On 07/26/2014 06:15 AM, 積丹尼 Dan Jacobson wrote: And indeed it does! But who would ever guess? Well, *you* figured it out. Plus, you deduced 999, an alternative that also works for all practical purposes. This stuff is documented in the coreutils manual. It's not clear that this particular detail is so important that it needs to be in the sleep --help output aka man page.
bug#18103: sleep infinity
PE == Paul Eggert egg...@cs.ucla.edu writes: PE This stuff is documented in the coreutils manual. It's not clear that PE this particular detail is so important that it needs to be in the PE sleep --help output aka man page. No seeming mention in coreutils: Installed: 8.21-1.2 500 http://ftp.br.debian.org/debian/ unstable/main i386 Packages Not on info sleep nor anywhere else in the coreutils manuals.
bug#18103: sleep infinity
On 07/26/2014 08:15 AM, 積丹尼 Dan Jacobson wrote: Not on info sleep nor anywhere else in the coreutils manuals. In my copy of the manual (from coreutils 8.23) 'info sleep' says GNU ‘sleep’ accepts arbitrary floating point numbers. *Note Floatingpoint::. and the note explains details.
bug#18103: sleep infinity
Indeed it says However, GNU `sleep' accepts arbitrary floating point numbers. *Note Floating point::. Alas infinity doesn't sound like an arbitrary floating point number. So maybe it should say arbitrary floating point numbers and infinity, else some people will give up instead of following the link. But OK I am old fashioned.
bug#18057: [PATCH] Find tail.c in srcdir, not builddir
On 07/23/2014 05:48 PM, Andreas Schwab wrote: Bernhard Voelker m...@bernhard-voelker.de writes: On 07/19/2014 05:26 PM, Andreas Schwab wrote: diff --git a/tests/tail-2/inotify-race.sh b/tests/tail-2/inotify-race.sh index c25f354..7140871 100755 --- a/tests/tail-2/inotify-race.sh +++ b/tests/tail-2/inotify-race.sh @@ -37,7 +37,7 @@ case $(cat gdb.out) in *) skip_ can't run gdb;; esac -break_src=$abs_top_builddir/src/tail.c +break_src=$abs_top_srcdir/src/tail.c break_line=$(grep -n ^tail_forever_inotify $break_src) || framework_failure_ break_line=$(echo $break_line | cut -d: -f1) || framework_failure_ Thanks for the patch. However, what's wrong with $abs_top_builddir? Is that a serious question? Please be constructive. Bernhard was referring to the other instances with VPATH issues, that may only be passing now accidentally. I.E.: git grep abs_top_builddir}\?/ thanks, Pádraig.
bug#17505: Pádraig: does this solve your consistency concern? (was bug#17505: dd statistics output)
On 07/26/2014 02:35 AM, Linda Walsh wrote: Pádraig: you may have missed this as it was a reply to an old thread, but, changing the subj and composing as new should prevent that (I hope) You were concerned that the user would get different outputs based on the previously suggested algorithm -- as well as possibly different output when SIGUSR1 came in. This idea seems to solve both of those -- so if the patch that was proposed for this was modified in line with this suggestion, would there be any further problems? Linda Walsh wrote: Found old bug, still open... Pádraig Brady wrote: On 07/16/2014 10:38 AM, Pádraig Brady wrote: http://bugs.gnu.org/17505#37 was proposed do the following automatically (depending on the amount output): 268435456 bytes (256 MiB) copied, 0.0248346 s, 10.8 GB/s However that wasn't applied due to inconsistency concerns. I'm still of the opinion that the change above would be a net gain, as the number in brackets is for human interpretation, and in the vast majority of cases would be the best representation for that. One patch that would not be inconsistent: If the user uses units of a single system (i.e. doesn't use 'si' and b2 units in same statement), then display the summary units using the same notation the user used: dd if=xx bs=256M ...(256M copied) vs. dd if=xx bs=256MB ...(256MB copied)... Note another reason to _not_ apply the patch is that requests to print the statistics can come async through SIGUSR1, and thus increase the chances of inconsistent output. Solves this too, since the units are decided when the command is parsed, so SIGUSR would use the same units as would come out on a final summary. Or is using consistent units w/what the user users not ok? Note, for statements w/o units (or mixed system), there would be no reason to change current behavior. That was the original approach but is a bit worse than the dynamic approach since it's common to specify transfer sizes in IEC units for SI sized data. BTW I was playing devil's advocate with my mention of the SIGUSR1 inconsistency. I'm still of the opinion that the dynamic switch of human units based on current transferred amount is the lesser of two evils, since this output is destined for human consumption. cheers, Pádraig.
bug#18057: [PATCH] Find tail.c in srcdir, not builddir
Pádraig Brady p...@draigbrady.com writes: Bernhard was referring to the other instances with VPATH issues, that may only be passing now accidentally. Please don't mix unrelated issues. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
