Follow-up Comment #1, bug #22109 (project coreutils):
Could you provide some more justification than would be nice please?
Implementing the change you suggest would significantly complicate the
implementation of tr, which is already quite fearsome; see for example the
recent discussion of the
Leo Butler [EMAIL PROTECTED] writes:
I don't know if this is relevant, but I have extracted the 2nd through 1000th
character in the 50GB file, and there appears to be garbage (unprintable
chars)
in the first line. The remainder of the extract looks fine. Moreover, I split
the file into
Leo Butler [EMAIL PROTECTED] writes:
sort rapidly chews up about 40-50% of total physical memory
That's weird. It shouldn't do that. It doesn't do that on my machine
(Debian stable x86, coreutils 6.10, compiled with GCC 4.2.2). Memory
usage goes up to 250 MB (as requested) and stays there.
Elias Pipping [EMAIL PROTECTED] wrote:
On Wed, Jan 23, 2008 at 01:40:22PM +0100, Jim Meyering wrote:
If that's the problem, here's an untested fix:
Unfortunately, that doesn't seem to help.
Thanks for checking.
That suggests there's a more fundamental problem.
Please do this as root:
cd
---
src/dircolors.hin |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/dircolors.hin b/src/dircolors.hin
index 838fa8f..3fb5a2f 100644
--- a/src/dircolors.hin
+++ b/src/dircolors.hin
@@ -30,6 +30,7 @@ TERM dtterm
TERM eterm-color
TERM gnome
TERM gnome-256color
+TERM
Paul Eggert wrote:
I ran into the following minor glitch when compiling coreutils 6.10 on
Solaris 8 sparc with GCC 4.2.2:
vasnprintf.c: In function 'vasnprintf':
vasnprintf.c:2196: warning: implicit declaration of function 'signbit'
Thanks for reporting this.
Here is a patch to the gnulib
URL:
http://savannah.gnu.org/bugs/?22121
Summary: chcon help output refers to lchown system call
Project: GNU Core Utilities
Submitted by: goeran
Submitted on: fredag 2008-01-25 den 21:35
Category: None
On Jan 8, 2008 5:46 PM, Jim Meyering [EMAIL PROTECTED] wrote:
If you're really motivated, there's another minor problem:
the include/exclude mechanism operates only on bin_PROGRAMS,
and not bin_SCRIPTS. That means --enable-no-install-program=groups
doesn't work, since groups is a script.
I
Richard Neill wrote on 25-01-08 14:57:
Only that multiple instances of tr, piped together is rather ugly, and
I, personally, strongly disagree.
bjd
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Update of bug #22109 (project coreutils):
Severity: 3 - Normal = 1 - Wish
Status:None = Wont Fix
Open/Closed:Open = Closed
Update of bug #22017 (project coreutils):
Status:None = Invalid
Open/Closed:Open = Closed
___
Reply to this item at:
Francky Leyn wrote:
Hello,
I'm seeking for some way to revert the order of lines. The first line
read thus must get out last and the last read must be output first.
Although it's easy to write a program for it, I'm wondering if this
is not possible with the UNIX toolbox. Any ideas?
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Francky Leyn on 1/25/2008 8:49 AM:
| I first tought of something like cat -r, where the r stand for reverse.
| Is this a good suggestion, or a bad one?
So good, that it is already implemented, as 'tac'.
- --
Don't work too hard, make
Update of bug #21999 (project coreutils):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Follow-up Comment #6:
as discussed via
James Youngman [EMAIL PROTECTED] wrote:
On Jan 8, 2008 5:46 PM, Jim Meyering [EMAIL PROTECTED] wrote:
If you're really motivated, there's another minor problem:
the include/exclude mechanism operates only on bin_PROGRAMS,
and not bin_SCRIPTS. That means --enable-no-install-program=groups
Leo Butler wrote:
-16 -2 -14 -5 1 1 0 0.3080808080808057 0 0.1540404040404028 0.3904338415207971
That should be fine.
I have a dual processor machine, with each processor being an Intel Core 2
Duo E6850, rated at 3GHz and cache 4096 kB, with 3.8GB total physical
memory and 4GB swap space
16 matches
Mail list logo
