Re: readlink(1) of more than one file?
On 12/13/2012 05:34 AM, Jim Meyering wrote: Jim Meyering wrote: ... The awkward/somewhat redundant -n, --no-newline option is handled in the same way as on BSD and the help text adjusted like: - -n, --no-newline do not output the trailing newline\n\ + -n, --no-newline do not output the separator character\n\ Good point. Now that the long-named --no-newline is a misnomer, we might want to provide a better long-named option (like --no-separator) and begin the deprecation process. E.g., warn that the --no-newline option is being deprecated, and add a FIXME to give an error in a few years. As I reread this, I think changing/deprecating is not worth the trouble after all. Yes the option itself is of marginal use, and so best just keep it around for compat with older GNU readlink and BSD's variant. thanks, Pádraig.
[coreutils] SHA-3
I suspect that coreutils developers are already aware of the final decision in the several-years-long NIST competition to come up with a followon to the SHA-1 and SHA-2 checksum algorithms. The winner (out of 64 submissions) was announced on 2-Oct-2012: NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition http://www.nist.gov/itl/csd/sha-100212.cfm SHA-3 https://en.wikipedia.org/wiki/SHA-3 If a near-term coreutils release can include an SHA-3 utility, even if an early version did not exploit assembly-level directives for squeezing the utmost in performance out of particular hardware, it will help make the new checksum algorithm more widely known. There is already work on SHA-3 reported on the gnupg-de...@gnupg.org list, with the first posting on 12-Dec-2012 (yesterday, as I write this), so it may be possible to use already-developed GPL-compatible code for inclusion in coreutils. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
[PATCH] two minor tweaks to HACKING
The first mentions 'git stash' in a relevant paragraph. The second changes parameters for 'lcov' example - the current parameters produce wrong output (the source files are not found, with LCOV version 1.9 ). -gordon From e1ece5ff278258a18a078cad1d8fbf65c7e4fe71 Mon Sep 17 00:00:00 2001 From: Assaf Gordon assafgor...@gmail.com Date: Thu, 13 Dec 2012 11:42:01 -0500 Subject: [PATCH 1/2] doc: mention git stash in HACKING --- HACKING |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/HACKING b/HACKING index f3f961a..84e9707 100644 --- a/HACKING +++ b/HACKING @@ -120,6 +120,8 @@ Note 2: sometimes the checkout will fail, telling you that your local modifications conflict with changes required to switch branches. However, in any case, you will *not* lose your uncommitted changes. +Run git stash to temporarily hide uncommited changes in your +local directory, restoring a clean working directory. Anyhow, get back onto your just-created branch: -- 1.7.7.4 From 8cd8f40882daa165ced8091697c158c7afb479d6 Mon Sep 17 00:00:00 2001 From: Assaf Gordon assafgor...@gmail.com Date: Thu, 13 Dec 2012 14:20:47 -0500 Subject: [PATCH 2/2] doc: tweak 'lcov' in HACKING Use the correct -b (--base-directory) parameter. --- HACKING |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/HACKING b/HACKING index 84e9707..8e4243f 100644 --- a/HACKING +++ b/HACKING @@ -610,8 +610,8 @@ to generate HTML coverage reports. Follow these steps: # run whatever tests you want, i.e.: make check # run lcov - lcov -t coreutils -q -d lib -b lib -o lib.lcov -c - lcov -t coreutils -q -d src -b src -o src.lcov -c + lcov -t coreutils -q -d lib -b `pwd` -o lib.lcov -c + lcov -t coreutils -q -d src -b `pwd` -o src.lcov -c # generate HTML from the output genhtml -p `pwd` -t coreutils -q --output-directory lcov-html *.lcov -- 1.7.7.4
Re: numfmt (=print 'human' sizes) updates
Hello, Attached is a slightly improved patch - minor code changes, and many more tests. Line coverage is 98%, and branch coverage is now 93% , and most of the non-covered branches are simply unreachable (I'm checking the reachable ones). The comments below still apply. - gordon Assaf Gordon wrote, On 12/13/2012 01:02 AM: Most of the previously raised issues have been addressed, except handling locale'd grouping in the input numbers (locale'd decimal-point is handled correctly). Added support for header, auto-whitespace-padding, floating-point input . Internally, all values are now stored as long double (instead of previously uintmax_t) - enables working with Yotta-scale values. The following should now 'just work' : df | ./src/numfmt --header --field 2 --to=si ls -l | ./src/numfmt --header --field 5 --to=iec ls -lh | ./src/numfmt --header --field 5 --from=iec --padding=10 The --debug option now behaves more like sort's --debug: prints messages to STDERR about possible bad combinations and inputs (which are not fatal errors): $./src/numfmt --debug 6 ./src/numfmt: no conversion option specified 6 The --devdebug option can be used to show internal states (perhaps will be removed once the program is finalized?). The test file 'tests/misc/numfmt.pl' contains many more tests and details about possible inputs/outputs. If the functionality is acceptable, the next steps are cleaner code and better documentations. numfmt.8.patch.xz Description: application/xz
bug#13172: tail: unrecognized file system type
Hi i've got a warning message in tail command: tail -f /vc/log/apache2/access_log - report to bug. tail (GNU coreutils) 8.20 Packaged by Gentoo (8.20 (p1.0)) - file system type ceph message: tail: unrecognized file system type 0x00c36400 for '/vc/log/apache2/access_log'. please report this to bug-coreutils@gnu.org. reverting to polling Regards: Conrad.
