Re: Human readable sort
Pádraig Brady wrote:
I was thinking that the mixed IEC/SI check
should be applied to each key separately rather
than globally. What do you think? Patch attached.
From ef06a30d122fc9ccac51a682a3abf6868d8832d6 Mon Sep 17 00:00:00 2001
...
-check_mixed_SI_IEC (char prefix)
+check_mixed_SI_IEC (char prefix, struct keyfield *key)
{
- static int seen_si = -1;
- bool si_present = prefix == 'i';
- if (seen_si != -1 seen_si != si_present)
+ int si_present = prefix == 'i';
+ if (key-si_present != -1 si_present != key-si_present)
error (SORT_FAILURE, 0, _(both SI and IEC prefixes present on units));
Good idea.
Not part of this change, I know, but that diagnostic should include a
file name. Imagine sorting many files, with many key specifiers (hence
many columns of data) and very many lines, yet only a few offenders.
With a file_name:line number (and byte/char-count?) and maybe even a
sample of the offending data, it'd be easier to spot and correct the
problem.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: README-prereq update
Jim Meyering wrote: Pádraig Brady wrote: automake-1.11 just went into Fedora 11 which started an interesting discussion :) https://www.redhat.com/archives/fedora-devel-list/2009-June/msg02451.html Anyway I've updated the development prerequisites doc to be more general in the attached patch. Thanks! That looks fine. Actually on reconsideration I also added some info to README-hacking and merged some specific requirements info from there to README-prereq. I think this fits much better now. cheers, Pádraig. From f19ddf91ab1b07a0403745d4b6d46ef061335602 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= padr...@pb-laptop.(none) Date: Mon, 22 Jun 2009 09:51:34 +0100 Subject: [PATCH] maint: generalize the development prerequisites docs * README-hacking: Add a little more high level info and merge notes on specific developer prerequisites into README-prereq * README-prereq: Remove the Fedora 8 specific information and generalize the information to be applicable to any system. --- README-hacking | 28 +++-- README-prereq | 92 ++-- 2 files changed, 61 insertions(+), 59 deletions(-) diff --git a/README-hacking b/README-hacking index 555128f..b72e54c 100644 --- a/README-hacking +++ b/README-hacking @@ -9,33 +9,15 @@ See also HACKING for more detailed coreutils contribution guidelines. We've opted to keep only the highest-level sources in the GIT repository. This eases our maintenance burden, (fewer merges etc.), but imposes more requirements on anyone wishing to build from the just-checked-out sources. -Specific tools and versions will be checked for and listed by the -bootstrap script shown below, and will include: - -- Automake http://www.gnu.org/software/automake/ -- Autoconf http://www.gnu.org/software/autoconf/ -- Bison http://www.gnu.org/software/bison/ -- Gettext http://www.gnu.org/software/gettext/ -- Git http://git.or.cz/ -- Gperf http://www.gnu.org/software/gperf/ -- Gzip http://www.gnu.org/software/gzip/ -- Perl http://www.cpan.org/ -- Rsync http://samba.anu.edu.au/rsync/ -- Tar http://www.gnu.org/software/tar/ - -- Valgrind +Note the requirements to build the released archive are much less and +are just the requirements of the standard ./configure make procedure. +Specific development tools and versions will be checked for and listed by +the bootstrap script. See README-prereq for specific notes on obtaining +these prerequisite tools. Valgrind http://valgrind.org/ is also highly recommended, if Valgrind supports your architecture. See also README-valgrind. -- XZ utils (successor to LZMA) - -This package's build procedure uses XZ to create a compressed -distribution tarball. Using this feature of Automake requires -version 1.10a or newer, as well as the xz program itself. -Make sure you have the latest version of the XZ Utils from -http://tukaani.org/xz/ - While building from a just-cloned source tree may require installing a few prerequisites, later, a plain `git pull make' should be sufficient. diff --git a/README-prereq b/README-prereq index f050410..5a23ba4 100644 --- a/README-prereq +++ b/README-prereq @@ -1,36 +1,56 @@ -Detailed below are concrete examples for -getting the prerequisites for particular systems. - -- GNU/Linux - fedora - - This shows the steps for getting the tools required to build coreutils - on a Fedora 8 system. We try to use official packages where possible. - The three methods described for making these required packages available - should help clarify build requirements on GNU/Linux systems. - - 1. Make sure the official distro git package is installed: -# yum install git - - 2. The distro autoconf is too old, but there is a newer one available - so we rebuild that and make it available to the full system: -# yum install emacs #autoconf build requires emacs (20MB) -# rpmbuild --rebuild http://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/autoconf-2.63-1.fc10.src.rpm -# rpm -Uvh /usr/src/redhat/RPMS/noarch/autoconf-2.63-1.fc8.noarch.rpm - Note Autoconf 2.62 or newer is needed to build automake-1.11 in step 3. - Apply the same method to build and install xz. - - 3. The latest stable automake (1.10.1) was not new enough, so we download - and build automake-1.11 or newer from its repository and make it available - just to coreutils: -# yum install help2man #required to build automake fully -$ git clone git://git.sv.gnu.org/automake.git -$ cd automake -$ git checkout -b branch-1.11 --track origin/branch-1.11 -$ ./bootstrap -$ ./configure --prefix=$HOME/coreutils/deps -$ make install - - Now we can build coreutils as described in README-hacking - as long as $PATH starts with $HOME/coreutils/deps/bin, which - one can set for the current shell like: -$ export PATH=$HOME/coreutils/deps/bin:$PATH +This gives some notes on obtaining the tools required for development. +I.E. the tools
Re: feature request: -0 option for tr
On Wed, Jul 1, 2009 at 11:47 AM, Craig Sandersc...@taz.net.au wrote: On Wed, Jul 01, 2009 at 10:13:15AM +0100, James Youngman wrote: The essential point though has already been made by Bob and Andreas; this causes failures for filenames which themselves contain newlines (all Unix-like filesystems I am familiar with allow this). i've already heard this stupid argument three times and it's as cretinous the fourth time as it was the first three. it's even more annoying to hear it again almost two days after i gave up the lost cause of getting anybody to actually give a damn about implementing a useful feature. but the really annoying thing about the argument is that it has nothing to do with my proposed feature. FILENAMES WITH NEWLINES ARE EXPLICITLY OUT OF THE FUCKING SCOPE OF THE REQUEST It's irrelevant whether you consider that case in scope or not, though. In the absence of external drivers (such as POSIX compatibility) the maintainers of the package (I don't maintain coreutils but I do maintain xargs) aren't going to implement a feature with a known design flaw - the fact that you personally don't care about the flaw is beside the point. SO HARPING ON ABOUT THEM NOT BEING CATERED TO IS CRIMINALLY FUCKING STUPID. is that in simple enough terms for you to understand? Of course I understand. The point is that you can't get rid of the edge cases (in this case, newlines in filenames) simply by wishing them away or saying I don't care. if you're too lazy or indifferent to implement a feature then have the guts to say so - as volunteers you have every right to say I don't want to do that - but don't make up lame bullshit excuses. But they're not excuses in that sense. You're facing a refusal to implement a bad idea. The refusal doesn't arise out of laziness. Where no file names contain newlines, the measure is not necessary anyway. actually, it is because the proposal wasn't about translating newlines in filenames. it was about changing the termination character from newline to null to make the input suitable for use with 'xargs -0' i would have thought it was obvious that newlines aren't the concern here, and never were. the point of using null terminated strings for input to xargs is to avoid problems with spaces and other punctuation characters. In that case use xargs -d not xargs -0. now fuck off and quit bothering me. i've wasted enough of my time on you losers. In these cases you might find it helpful to defer replying until the initial surge of anger on finding that other people don't agree with you has subsided. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: add min and max to coreutils?
Joshua Bronson wrote:
I was looking for a command line utility to get the min and max from a file
(rather than the much less efficient sort | {head,tail} -1) and I couldn't
find one. Someone on linuxquestions.org directed me toward the Generic
Mapping Tools http://gmt.soest.hawaii.edu/, which provide a minmax
utility, and though it would get the job done it's not exactly what I was
looking for (not to mention I have no need for the ~60 other utilities in
the package).
Yes, http://gmt.soest.hawaii.edu/gmt/doc/gmt/html/man/minmax.html is a
bit complicated and not very generic.
Perhaps http://suso.suso.org/programs/num-utils/ would be
more appropriate for you?
As the provider of sort, would coreutils be the appropriate
package to provide min and max tools with a similar interface (e.g.
accepting -n and such)?
That's an interesting suggestion. I'm not sure about separate tools,
especially considering the num-utils package above. Though perhaps
adding --{head,tail} options to sort would be appropriate as one could
then use a O(n*m) algorithm in sort where m is the parameter to --head
and n is the number of input lines. Also it would be a lot more memory
efficient and one would get the key processing functionality of sort.
I'm not sure about doing that at all though.
cheers,
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: add optional $DESTDIR support to install
Etienne Laurin wrote: Hello, By modifying install to support DESTDIR I was able to effortlessly create packages for many source distributions that do not support DESTDIR but use install. This patch adds the -P and --destdir options, which, if present, prefix their argument or the value of $DESTDIR to the destination. But if you need to change the package to add the -P option, you might as well make it support DESTDIR? Using -P would make your package dependent on a new version of coreutils and also would miss packages that use cp, ln etc. Please consider adding this functionality to install. Something similar was discussed recently: http://lists.gnu.org/archive/html/bug-coreutils/2009-02/msg00047.html cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: README-prereq update
Pádraig Brady wrote: Jim Meyering wrote: Pádraig Brady wrote: automake-1.11 just went into Fedora 11 which started an interesting discussion :) https://www.redhat.com/archives/fedora-devel-list/2009-June/msg02451.html Anyway I've updated the development prerequisites doc to be more general in the attached patch. Thanks! That looks fine. Actually on reconsideration I also added some info to README-hacking and merged some specific requirements info from there to README-prereq. I think this fits much better now. Better still. Thanks! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: -0 option for tr
are you to stupid to understand the words fuck off? i have no interest in arguing with you. or communicating with you in any way. is it that important to you to revive debate over a proposal i abandoned three days ago just so your loser ego can have it's two cents worth? well, you know where you can shove your two cents. now fuck off and stop bothering me. craig -- craig sanders c...@taz.net.au ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] tail: add comments noting potential inotify-related problems
Hi Jim,
I took a look at the problems you reported. The first one is fixed with
the first attached patch.
I have tested it under Linux 2.6.18-6-xen-686.
tail -F works until the parent directory is not removed and it is very
related to the second problem you showed. At this point I think the
best way is to find a solution to both, using a tree instead of a hash
map. What do you think?
Thanks,
Giuseppe
Jim Meyering j...@meyering.net writes:
Hi Giuseppe,
I noticed two potential problems.
The first appears to affects only kernels 2.6.13..2.6.20.
The second one doesn't have to be fixed before the upcoming release.
From 8fbe1d2d1f666a0428f41d03831e18d4d1b56e89 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Thu, 2 Jul 2009 23:38:46 +0200
Subject: [PATCH 1/2] tail: avoid a problem for kernels prior to 2.6.21
* src/tail.c (tail_forever_inotify): Handle the special case that the
inotify watcher returns zero bytes.
---
src/tail.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/tail.c b/src/tail.c
index 89c43b8..a99091a 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1259,8 +1259,9 @@ tail_forever_inotify (int wd, struct File_spec *f, int
n_files)
evbuf_off = 0;
/* For kernels prior to 2.6.21, read returns 0 when the buffer
- is too small. FIXME: handle that. */
- if (len == SAFE_READ_ERROR errno == EINVAL max_realloc--)
+ is too small. */
+ if ((len == 0 || (len == SAFE_READ_ERROR errno == EINVAL))
+ max_realloc--)
{
len = 0;
evlen *= 2;
@@ -1268,7 +1269,7 @@ tail_forever_inotify (int wd, struct File_spec *f, int
n_files)
continue;
}
- if (len == SAFE_READ_ERROR)
+ if (len == SAFE_READ_ERROR || len == 0)
error (EXIT_FAILURE, errno, _(error reading inotify event));
}
--
1.6.3.3
From bfbd6a82055326ea45882664890a5e77aa3bb2a1 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Thu, 2 Jul 2009 23:40:40 +0200
Subject: [PATCH 2/2] tail: fixed a test case
* tests/tail-2/wait: Be sure the `not_accessible' file is really not
accessible before try to tail -f it.
---
tests/tail-2/wait | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/tests/tail-2/wait b/tests/tail-2/wait
index 7eee8b1..8f2f610 100755
--- a/tests/tail-2/wait
+++ b/tests/tail-2/wait
@@ -45,17 +45,20 @@ if test -n $state; then
kill $pid
fi
-tail -s0.1 -f not_accessible
-pid=$!
-sleep .5
-state=$(get_process_status_ $pid)
-
-if test -n $state; then
- case $state in
-S*) echo $0: process still active 12; fail=1 ;;
-*) ;;
- esac
- kill $pid
+# Check if the file is really not accessible before use it.
+if ! cat not_accessible; then
+tail -s0.1 -f not_accessible
+pid=$!
+sleep .5
+state=$(get_process_status_ $pid)
+
+if test -n $state; then
+case $state in
+S*) echo $0: process still active 12; fail=1 ;;
+*) ;;
+esac
+kill $pid
+fi
fi
(tail -s0.1 -f here 2tail.err)
--
1.6.3.3
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: add min and max to coreutils?
2009/7/2 Pádraig Brady p...@draigbrady.com
Joshua Bronson wrote:
I was looking for a command line utility to get the min and max from a
file
(rather than the much less efficient sort | {head,tail} -1) and I
couldn't
find one. Someone on linuxquestions.org directed me toward the Generic
Mapping Tools http://gmt.soest.hawaii.edu/, which provide a minmax
utility, and though it would get the job done it's not exactly what I was
looking for (not to mention I have no need for the ~60 other utilities in
the package).
Yes, http://gmt.soest.hawaii.edu/gmt/doc/gmt/html/man/minmax.html is a
bit complicated and not very generic.
Perhaps http://suso.suso.org/programs/num-utils/ would be
more appropriate for you?
It would, thank you.
http://suso.suso.org/programs/num-utils/man1/bound.htmlis definitely
more like what I had in mind.
As the provider of sort, would coreutils be the appropriate
package to provide min and max tools with a similar interface (e.g.
accepting -n and such)?
That's an interesting suggestion. I'm not sure about separate tools,
especially considering the num-utils package above. Though perhaps
adding --{head,tail} options to sort would be appropriate as one could
then use a O(n*m) algorithm in sort where m is the parameter to --head
and n is the number of input lines. Also it would be a lot more memory
efficient and one would get the key processing functionality of sort.
The more general idea of having sort accept an argument to output only the
k largest or smallest elements was another idea I had and would love to see
implemented. FWIW, though it provides bound, num-utils does not seem to
provide a facility for top (bottom) k. Also, the comparative prevalence of
coreutils versus num-utils is another compelling reason to add it here.
I'm not sure about doing that at all though.
What are your concerns?
cheers,
Pádraig.
Thanks for your reply.
Josh
P.S. http://en.wikipedia.org/wiki/Selection_algorithm has a relevant section
(search for Selecting k smallest or largest elements).
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
