Re: GSoC idea proposal

Glen Lenker wrote: > I saw that the GNU project is a mentoring organization for this years > Google Summer of Code. Would it be possible to extend my work on > optimizing sort to this summer? Great, Karl has done that: http://socghop.appspot.com/org/show/google/gsoc2009/karlberry http://www.gnu.or

Re: [PATCH] tests: copy.c destination permissions lost when backup specified

Sami Kerola wrote: > I give great value for backups, but still I would like to see new and > old destination files to have same permissions. Of course when > --preserve is specified expectation is changed; source permission > should appear for the new file. I agree with Jim. Backup file should mai

Re: Feature Request: List files/directories lexicographically

Adam Gordon wrote: > This seems like it would be a simple feature and while it may overlap > with (or be slightly redundant to) the sort command, sorting > lexicographically, i.e., foo1, foo2, foo10, foo20 instead of foo1, > foo10, foo2, foo20, would be a nice feature to have. Does `ls -v` do what

Re: Feature Request: List files/directories lexicographically

Pádraig Brady wrote: > Adam Gordon wrote: >> This seems like it would be a simple feature and while it may overlap >> with (or be slightly redundant to) the sort command, sorting >> lexicographically, i.e., foo1, foo2, foo10, foo20 instead of foo1, >> foo10, foo2, foo20,

Re: [patch #6797] shred option to use internal RNG

Steven Schveighoffer wrote: > URL: > > > Summary: shred option to use internal RNG > > Our company is looking at using GNU shred to wipe customer data from RMA'd > drives in our systems. > > One thing we have noticed is that shred runs abo

Re: git version and automake 1.10b question

Jim Meyering wrote: > diff --git a/README-prereq b/README-prereq > -$ cd automake && ./configure --prefix=$HOME/coreutils/deps > +$ cd automake > +$ git checkout --track origin/next -b next > +$ ./configure --prefix=$HOME/coreutils/deps I needed to switch the git checkout paramete

Re: [patch #6797] shred option to use internal RNG

Steven Schveighoffer wrote: > Follow-up Comment #4, patch #6797 (project coreutils): > > Thanks for the suggestion, but I really don't understand the reluctance to > utilize the (already implemented) internal random number generator. It's > there, it costs nothing extra to use it, it doesn't requ

Re: RFC: changing the "+" in ls -l output to be "." or "+"

Just a quick follow up to this now archived bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472590 The last message there mentioned selinux query overhead. On my system with selinux disabled, there is currently a significant overhead in doing the selinux lookup per file with a standard `ls -

Re: mkfile -- create large files efficiently

Matej Cepl wrote: > OK, another turn around of fixes. This is just the last patch, > whole branch is available at > http://github.com/mcepl/coreutils/tree/truncate-fallocate (repo > URL is git://github.com/mcepl/coreutils.git). > > One note about this patch is that I have unsuccesfully tried to >

Re: [patch #6797] shred option to use internal RNG

James Youngman wrote: > Follow-up Comment #5, patch #6797 (project coreutils): > > IMO both /dev/urandom and /dev/random should be used as sources of data for > seeding PRNGs, as opposed to being used as sources of random data directly. > My rationale for this is that even using /dev/urandom for

Re: RFC: changing the "+" in ls -l output to be "." or "+"

Jim Meyering wrote: > You might want to do something similar to what I did in fts.c > with this change: > > http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507 Oh cool, thanks for that. I'll also look at documenting the ls SElinux options in the info docs as I couldn't see them o

[PATCH] maint: remove compiler warnings from randint and randread modules

A small patch to remove compiler warnings I noticed while compiling these modules for the shred speedups. cheers, Pádraig. >From 94135b46056b93590cce603950db5a3f4e33aa15 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Mon, 6 Apr 2009 12:23:26 +0100 Subject: [PATCH] maint: re

Re: [patch #6797] shred option to use internal RNG

Pádraig Brady wrote: > So in summary I would do: > > 1. by default always use internal PRNG seeded with getpid() > 2. if --random-source specified read all random data from there > > Note 2 will allow one to specify /dev/zero if desired. > We could seed our PRNG with /dev

Re: Parallelizing sort

Pádraig Brady wrote: > Glen Lenker wrote: >> On Wed, Feb 11, 2009 at 10:12:42PM -0800, Nima Nikzad wrote: >>> Hello coreutils community, >>> I am new to the exciting world of open source development and thought I >>> should introduce my self and get some f

Re: [PATCH] df: new option --direct to not resolve a mount point

Kamil Dudka wrote: > Hello, > > I am attaching a single patch for df adding a new option --direct to not > resolve mount point and show statistics directly for a file. It can be > especially useful for NFS mount points if there is a boundary between two > storage policies behind the mount point

Re: RFC: changing the "+" in ls -l output to be "." or "+"

Jim Meyering wrote: > Pádraig Brady wrote: > ... >> I'll also look at documenting the ls SElinux options in the info docs >> as I couldn't see them on a quick search. > > Nice. That will we welcome. > If you feel really industrious, mktemp needs info document

Re: RFC: changing the "+" in ls -l output to be "." or "+"

Pádraig Brady wrote: > Jim Meyering wrote: >> You might want to do something similar to what I did in fts.c >> with this change: >> >> http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507 > > Oh cool, thanks for that. Hmm, looks like my Fedo

[PATCH] deprecating install --preserve_context as per the FIXME

`install --preserve-context` is the preferred method. >From 06dad629bb1b3d5bf6529e20677893374d0fec48 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Tue, 7 Apr 2009 14:14:58 +0100 Subject: [PATCH] install: deprecate the --preserve_context option src/install.c: Print a warnin

Re: [patch #6797] shred option to use internal RNG

Jim Meyering wrote: > Thanks for doing that. > At first glance, you got it all. > Except maybe the texinfo documentation... > Yep. There's a mention of shred in the "Random sources" section. > So now we'd have to say how shred's --random-source works > and that its default is different from those

Re: RFC: changing the "+" in ls -l output to be "." or "+"

Jim Meyering wrote: > Pádraig Brady wrote: >> Pádraig Brady wrote: >>> Jim Meyering wrote: >>>> You might want to do something similar to what I did in fts.c >>>> with this change: >>>> >>>> http://git.sv.gnu.org/cgit/gnulib.g

Re: [patch #6797] shred option to use internal RNG

Pádraig Brady wrote: > Jim Meyering wrote: >> Thanks for doing that. >> At first glance, you got it all. >> Except maybe the texinfo documentation... >> Yep. There's a mention of shred in the "Random sources" section. >> So now we'd have to

Re: RFC: changing the "+" in ls -l output to be "." or "+"

Andreas Schwab wrote: > Pádraig Brady writes: > >> @@ -8045,6 +8055,15 @@ ownership of installed files or directories to >> @var{owner}. The default >> is @code{root}. @var{owner} may be either a user name or a numeric user >> ID. >> >> +...@it

Re: [PATCH] df: new option --direct to not resolve a mount point

Kamil Dudka wrote: > On Tuesday 07 of April 2009 14:22:38 Pádraig Brady wrote: >> Kamil Dudka wrote: >>> Hello, >>> >>> I am attaching a single patch for df adding a new option --direct to not >>> resolve mount point and show statistics directly for a

Re: inifite loop in recent mgetgroups.c:mgetgroups on Darwin/MacOS

Steven Parkes wrote: > Sorry; that patch was bogus. This one is not, though I still don't like that > it returns the wrong result: > > diff --git a/gl/lib/mgetgroups.c b/gl/lib/mgetgroups.c > index e697013..b3a2a1a 100644 > --- a/gl/lib/mgetgroups.c > +++ b/gl/lib/mgetgroups.c > @@ -94,6 +94,11 @@

Re: inifite loop in recent mgetgroups.c:mgetgroups on Darwin/MacOS

Steven Parkes wrote: > Very similar to my "correct" patch. There's one other issue I found when I > was coming up with a patch which is that Darwin:getgrouplist also doesn't > return the number of groups. It sets the in/out parameter, but then just > returns 0. Right so your previous patch would h

Re: touch gets stuck for named pipes

Jim Meyering wrote: > ipif wrote: >> I'm using coreutils-7.2 on an embedded sparc V8 with linux-2.6.21 and >> uclibc-0.9.30. >> The problem is, that in utime.c(73) it is tried to read a char from the file >> and to write it back. As the fifo is empty touch gets stuck waiting for >> input. >> Becaus

Re: touch gets stuck for named pipes

Andreas Schwab wrote: > Pádraig Brady writes: > >> So would this simplification be appropriate, which just handles systems >> where utime("file", &ut); is OK while utime("file", NULL); is not? > > Note that utime(,0) requires less privileges th

Re: inifite loop in recent mgetgroups.c:mgetgroups on Darwin/MacOS

Jim Meyering wrote: > Pádraig Brady wrote: > .. > > Hi Pádraig, > Thanks for working on that. > > This NEWS entry makes it look like these are coreutils bugs. > True, it's a regression, but not due to a bug in coreutils, > unless you count the decision to use POSI

Re: small patches, e.g., update gnulib for ls -v & sort -V; fix a typo

all look sensible to me ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: possible patch for coreutils-7.2 tests/mv/i-3 test failure

John Stanley wrote: > Hi, > I just attempted to build coreutils-7.2 (GNU/Linux i686, linux-2.6.29.1) > for my home linux system(s) and found 1 test failure (tests/mv/i-3) > which did not occur in version 7.1 because the test was skipped (line > 29: skip_test_ FIXME: skip, until portability of trap

mgetgroups realloc issues

Hi, In regard to the realloc() introduced to mgetgroups.c, I'm not exactly sure but I think the diff below is required to handle realloc(,0) on glibc. I.E. I think a double free would have been done and an error reported if max_n_groups == 0 (which I presume is possible)? diff --git a/gl/lib/mge

Re: cp oddity

Adrian Revill wrote: > Hi, > > I am not sure if this is a bug, but would appreciate some advise. > If i use a single cp to copy multiple files, then read the files in > inode order. I see faster disk access times than if i copy each file > individually. > > cp -a /data/A /test/ > cp /data/A/* /te

Re: mgetgroups realloc issues

Jim Meyering wrote: > > Your change looks safe, so you might as well do that. > But if you do make the change, please add an explanatory comment. updated patch attached. cheers, Pádraig. >From 93a4f892ffe2ce005a32a1b92640f061f36c0d0c Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?

Re: [PATCH] sort: Add --threads option, which parallelizes internal sort.

Ralf Wildenhues wrote: > > I've looked at this in a bit more detail; no big conclusion but maybe > a few more hints that could help. > > I am now pretty confident that your patch implements the threading > correctly. When inserting some > expensive_computation (); > > in the sortlines functio

Re: [PATCH] in place option for unexpand

Sami Kerola wrote: > On Fri, Mar 27, 2009 at 15:20, Sami Kerola wrote: > >> Well I changed rename to copy that is part of coreutils and use the >> call in move_mode. I did not send new patch because I want to be sure >> my employer has signed papers stating that they have no right to my >> contri

Re: Coreutils Installation prerequisites

Manuel Richmond wrote: > > I am looking for the Installation prerequisites, any help will be appreciated http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=README-prereq;hb=HEAD Note also the bootstrap step documented there will check your system for required packages as defined in the

Re: join utility segfults

Roman Kirillov wrote: > Hi guys, > > Probably found a bug in 'join': > > [kiril...@chiark py-src]$ join s1.txt s2.txt > Segmentation fault > > files: http://sigizmund.info/upload/s12.tgz (28 mb) This issue seems related to the i18n patch applied by your distro ~/git/coreutils/src$ ./join s1.tx

Re: join utility segfults

Pádraig Brady wrote: > Roman Kirillov wrote: >> Hi guys, >> >> Probably found a bug in 'join': >> >> [kiril...@chiark py-src]$ join s1.txt s2.txt >> Segmentation fault >> >> files: http://sigizmund.info/upload/s12.tgz (28 mb) > >

Re: Human readable sort

Michael Speer wrote: > I wrote the following patch to the 7.2 branch of coreutils to allow > `sort` to sort by human readable byte sizes. I looked around a bit to > see what the status of previous attempts to integrate this > functionality were, but didn't see any very recent activity. This is >

Re: Human readable sort

Michael Speer wrote: > That's much more readable. I tacked in a size. Good catch. The size is required or otherwise one could get undefined results for some chars. > The standards do not > reference the lowercase letters you commented out, so I just deleted > them outright. Fair enough. >> Som

Re: Human readable sort

Michael Speer wrote: > 2009/4/25 Pádraig Brady : >> I've further modified your latest in the attached. >> I refactored the suffix finding a bit and also added >> support for --sort=human-numeric. > > I refactored it again to handle some potential problems with how

Re: Human readable sort

Michael Speer wrote: > 2009/4/25 Pádraig Brady : >> I've further modified your latest in the attached. >> I refactored the suffix finding a bit and also added >> support for --sort=human-numeric. > > I refactored it again to handle some potential problems with how

Re: Human readable sort

Pádraig Brady wrote: > seconds to sort 1 million ints: > --- > sort optiontime difference > --- > -n 2.75 > -h (ret 0) 3.10 +13% > -h 3.96 +44% I removed

Re: coreutils-7.3 release imminent

Jim Meyering wrote: > Just a heads up that there is now more than enough > reason to make a new, stable release of coreutils. > > I expect to review and apply Ondrej's xattr-related patches, > and then make a test release. Then (as usual, barring problems), > a day or so later I'll release coreut

Re: coreutils-7.3 release imminent

Jim Meyering wrote: > Pádraig Brady wrote: >> Jim Meyering wrote: >>> Just a heads up that there is now more than enough >>> reason to make a new, stable release of coreutils. >>> >>> I expect to review and apply Ondrej's xattr-related patches,

Re: Human readable sort

knome@gmail.com wrote: > On Apr 27, 2009 11:41am, Ondřej Vašík wrote: >> Pádraig Brady wrote: >> >> > Pádraig Brady wrote: >> >> > Attached is the full patch, which hopefully we can push soon. >> >> >> >> I'm not objecti

Re: dd manpage formatting for FLAG symbols

Werner Fischer wrote: > The dd manpage still has an formattig error in the section which > describes the FLAGS: > > The issue was reported in this posting: > http://lists.gnu.org/archive/html/bug-coreutils/2008-07/msg00170.html > ("dd: adjust --help output so help2man formats the man page properly

Re: uniq/sort documentation flaw

Andries E. Brouwer wrote: > uniq(1) says > >Discard all but one of successive identical lines from INPUT > > However, this is very misleading. "Identical" does not mean identical > but "equal if one ignores differences that LC_COLLATE says should be ignored". > > This man page line shoul

Re: uniq/sort documentation flaw

Jim Meyering wrote: > > Thanks. > One suggestion: > >> From: =?utf-8?q?P=C3=A1draig=20Brady?= >> diff --git a/src/uniq.c b/src/uniq.c >> -Discard all but one of successive identical lines from INPUT (or\n\ >> -standard input), writing to OUTPUT (or standard output).\n\ >> +Filter adjacent matchi

Re: uniq feature request: check-fields option

Steve Ward wrote: > For the uniq program, these options exist: > > --skip-chars=N > avoid comparing the first N characters > > --skip-fields=N > avoid comparing the first N fields > > --check-chars=N > compare no more than N characters in lines > > > It would be nice to have: > >

Re: coreutils-7.4: make check fails under Solaris 8

Christophe LYON wrote: > Hello, > > I have just tried coreutils-7.4 on a Solaris machine (built with > GCC-4.2.0). > > "make check" fails on misc/date-next-dow: > date-next-dow: test dow2: stdout mismatch, comparing dow2.O (actual) and > dow2.1 (expected) > *** dow2.OTue May 12 15:06:24 2009

Re: coreutils-7.4: make check fails under Solaris 8

Christophe LYON wrote: > >> >> I'm guessing the Solaris 8 system strftime() (called by Perl) >> doesn't support %F, whereas `date +%F` is using a gnulib replacement? >> This can be replaced I think with "%Y-%m-%d", as in the diff below. >> > > Thanks, you patches indeed fixes the problem. > > No

Re: coreutils-7.4: make check fails under Solaris 8

Christophe LYON wrote: > >> >> Weird. Can you run the following, hit ^D and post the log: >> >> truss -o log src/sort >> > Sure, here it is. ioctl(0, TCGETA, 0xFFBEF154)= 0 read(0, 0xFF2C35EC, 1024) (sleeping...) read(0, "\n", 1024) = 1 read(0

Re: Feature request: handling space-delimited data with cut

Eric Blake wrote: > According to Andrew McGill on 5/15/2009 4:10 AM: >> * There is no SIMPLE tool for handling space delimited data ({'$awk'} is not >>simple, IMHO) > > awk may not be as simple as some other tools, but it is standardized by > POSIX and is the application of choice for portabl

Re: say when comm separator disappears

jida...@jidanni.org wrote: > In (info "(coreutils)comm invocation"), after: > > With no options, `comm' produces three-column output. Column one >contains lines unique to FILE1, column two contains lines unique to >FILE2, and column three contains lines common to both files. Column

Re: Feature request: handling space-delimited data with cut

Jim Meyering wrote: > Pádraig Brady wrote: > > Hi Pádraig, > >> 90% of the time I use cut, I want it to split on whitespace. > > Same here (though usually SP+TAB are all I care about). > That's why when I insist on using cut, I'd first filter the

Re: say when comm separator disappears

Pádraig Brady wrote: > jida...@jidanni.org wrote: >> In (info "(coreutils)comm invocation"), after: >> >> With no options, `comm' produces three-column output. Column one >>contains lines unique to FILE1, column two contains lines unique to &g

[bug #24974] Document that comm's option "-1", "-2" and "-3" can be combined

Update of bug #24974 (project coreutils): Assigned to:None => pixelbeat Open/Closed:Open => Closed ___ Follow-up Comment #1: Addressed with h

[bug #25406] date command, using --date option, only sees out 6 days.

Update of bug #25406 (project coreutils): Assigned to:None => meyering Open/Closed:Open => Closed ___ Follow-up Comment #2: Fixed in release

Re: tail +n does not work under Linux?

Eric Blake wrote: > > What do you think about the attached patch to the --help output (and thus > man page)? Yes there are too many "N"s. > - -n, --lines=Noutput the last N lines, instead of the last > %d;\n\ > - or use +N to output lines starting with the

Re: [PATCH] chroot specify user/group feature

Giuseppe Scrivano wrote: > diff --git a/src/chroot.c b/src/chroot.c > + > +#ifndef GID_T_MAX > +# define GID_T_MAX TYPE_MAXIMUM (gid_t) > +#endif The above is redundant and already done in system.h > + > +#ifndef MAXGID > +# define MAXGID GID_T_MAX > +#endif Why add the new MAXGID name? > + if

[PATCH] New fallocate module

Pádraig Brady wrote: > > I noticed another thread with more info about fallocate: > https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html > > That got me thinking about whether we should use fallocate() > if available in cp etc. so ext4 etc. can allocate o

Re: Human readable sort

knome@gmail.com wrote: > On Apr 27, 2009 11:27am, Pádraig Brady wrote: >> >> It seems like you'll need to go through the copyright assignment >> > > I will start this process as soon as possible. > > The -h seems to run faster than -n on my d

Re: Human readable sort

Eric Blake wrote: > Pádraig Brady draigBrady.com> writes: > >> Looks like your copyright assignment papers went through. >> Attached is the latest patch rebased against master >> and with a couple of extra whitespace fixups. >> > > +static int

Re: Human readable sort

Jim Meyering wrote: > Pádraig Brady wrote: >> Eric Blake wrote: >>> Pádraig Brady draigBrady.com> writes: > ... >>> +static int >>> +find_unit_order (const char *number) >>> +{ >>> + static const char orders [UCHAR_LIM] = { >>&g

Re: [PATCH] dd: do not unnecesarilly allocate memory for input block size, when not needed

Ondřej Vašík wrote: > Hello, > as reported in https://bugzilla.redhat.com/show_bug.cgi?id=502026, in dd > is an unnecessary memory allocation for input block even if input block > buffer is not needed (skip and count set to 0). Attached patch should > prevent memory exhaustion error in that very sp

Re: [PATCH] New fallocate module

Bruno Haible wrote: > Hello Pádraig, > > The documentation files you sent document the status before any 'fallocate' > module is added to gnulib. So I committed them for you: > > 2009-05-21 Pádraig Brady > > * doc/glibc-functions/fallocate.texi: N

Re: [PATCH] dd: do not unnecesarilly allocate memory for input block size, when not needed

Ondřej Vašík wrote: > Pádraig Brady wrote: >> So that would not run skip(STDOUT_FILENO,...) if count==0. >> Would this break existing scripts that for example used >> this command to position a non seekable device? >> >> dd count=0 of=/dev/tape seek=1234 > &

Re: [PATCH] New fallocate module

Paul Eggert wrote: > Pádraig Brady writes: > >> Well libc, kernel or filesystem could return ENOSYS >> so code using fallocate() has to handle it anyway. > > If memory serves, ordinarily gnulib tries to catch such situations, > and to substitute a working function

Re: ls -l|head seems to look at all files in directory

Kamil Dudka wrote: > On Monday 25 of May 2009 15:43:50 Reuben Thomas wrote: >> Hi, >> >> If I do "ls -l |head" on a directory with many files in it, it takes a long >> time to complete, suggesting that it has read the entire directory. Since >> no sorting is involved, why has it done this? > > If

Re: ls -l|head seems to look at all files in directory

Reuben Thomas wrote: > On Mon, 25 May 2009, Jim Meyering wrote: > >> To do what he wants you have to know that ls -1U is the only >> way to get one output entry per readdir call. >> >> Reuben, you want to do it like this: >> >> ls -1U|head|xargs ls -l > > Thanks for the hint about -1, but this d

Re: Human readable sort

Jim Meyering wrote: > > Please make one small change to that log message: > > s/ -human/ --human/ > > And in the documentation, > > +Sort numerically, as per the @option{--numeric-sort} option, > +and in addition handle IEC or SI suffixes like MiB, MB etc. > +Note a mixture of these s

Re: "tr" fails to work with unicode strings

Roman Mamedov wrote: > Hello. > > Looks like the "tr" program does not work with UTF-8 strings properly. > I am attaching a screenshot. > This is with tr from GNU coreutils version 6.10. This is a known issue. We're working on it. thanks, Pádraig. __

Re: [PATCH] New fallocate module

Take 2 attached. Still outstanding from the gnulib portion is support for solaris. I may get time to set this up, but I've very little time lately, so I would like not to require this for merging. Also I didn't yet implement the optimization to coreutils that Paul mentioned, to cache whether the

Re: [PATCH] New fallocate module

Bruno Haible wrote: > Pádraig Brady wrote: >> Take 2 attached. > > Take 2 review: > >> +#ifdef REPLACE_FALLOCATE > > The generated fcntl.h should be maximally standalone. Can you better use > #if @REPLACE_FALLOCATE@ and use an AC_SUBSTed variable REPLACE_FALL

Re: [PATCH] New fallocate module

Pádraig Brady wrote: > Bruno Haible wrote: >> >> The return value convention described in >> http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html >> is a different one. Either this code or that man page is wrong. > > I don't follow.

Re: tail +n does not work under Linux?

Eric Blake wrote: > According to Eric Blake on 5/20/2009 8:20 AM: >>> CNT doesn't read too well :) >>> How about COUNT or NUM? >> COUNT runs into length problems - adding 4 characters per instance builds up >> fast. I'll try with NUM instead. As it is, I already had to rephrase >> things >> si

Re: README-prereq update

Matěj Cepl wrote: > With Fedora 11 and Fedora 8 long time obsolete, I think update of > README-prereq is due. Suggested patch is attached. Well the idea of that file was not to present how to build on the latest and greatest, but to present various methods available to get prerequisites. cheers,

Re: README-prereq update

Matěj Cepl wrote: > Pádraig Brady píše v Út 02. 06. 2009 v 16:15 +0100: >> Well the idea of that file was not to present how to build >> on the latest and greatest, but to present various methods >> available to get prerequisites. > > hmm, OK, except that the advice

Re: README-prereq update

Pádraig Brady wrote: > Matěj Cepl wrote: >> But, yes not a big deal, and one >> should probably be able to deal with prerequisites without help. > > I wouldn't say that at all. > README-prereq should be as accurate as possible. > > I'll update the au

Re: fyi, minor doc and dircolors+xz changes

Jim Meyering wrote: > > diff --git a/README-prereq b/README-prereq > index f9bf781..3660db5 100644 > --- a/README-prereq > +++ b/README-prereq > @@ -17,8 +17,7 @@ getting the prerequisites for particular systems. > # rpmbuild --rebuild > http://download.fedora.redhat.com/pub/fedora/linux/dev

Re: fyi, minor doc and dircolors+xz changes

Pádraig Brady wrote: > Jim Meyering wrote: >> diff --git a/README-prereq b/README-prereq >> index f9bf781..3660db5 100644 >> --- a/README-prereq >> +++ b/README-prereq >> @@ -17,8 +17,7 @@ getting the prerequisites for particular systems. >

Re: wc support for different tab widths

Bob Proulx wrote: > Hello Sebastian, > > Sebastian Bozlee wrote: >> I'm sorry if this is the wrong place to post this. > > This is the right place for discussion about 'wc' and development for > it. Along with any of the other coreutils. > >> This is my first contribution to an open source proj

[PATCH] maint: use a wildcard to include all syntax check exceptions in dist

I noticed a couple of syntax check exception files missing from the distribution tarball. Specifically .x-sc_require_config_h_first and .x-sc_error_message_uppercase The attached patch changes things so we don't have to maintain the list. cheers, Pádraig. >From 2f6339766a0f32ab709b2ab2fc24c67b5b0

Re: [egg...@cs.ucla.edu: Re: sort -N patch: sort in natural order]

Martin Sarfy wrote: > Hello, > > attached there is a patch against coreutils-6.10/sort.c implementing > "Natural order sorting" (e.g. "A1" < "A2" < "A10"), using "-N" parameter. > > Please, consider it's inclusion in upstream :-) > > Signing papers with copyright is not a problem. > > Best rega

Re: Not sure how to best reply re: dir_colors situation

Kamil Dudka wrote: > I think we should improve documentation a bit. It is not only about hard > links. Some people may also want to disable file capabilities highlighting, > etc. Pádraig, what do you think? Well as discussed previously I'm not fond of this feature at all: http://lists.gnu.org/ar

Re: SEQ

Name Famil wrote: > Hello, I apologize using an automatic translator > > for i in seq (A.. F) # All options from A to F > for i in seq (0 .. 9) # All the options from 0 to 9 > # And how to say all the options of printing? > length "all options" = 10 > > for i in seq {0..ZZ } ? > > 1 > 2

Re: Not sure how to best reply re: dir_colors situation

Kamil Dudka wrote: > On Saturday 06 of June 2009 16:30:05 Pádraig Brady wrote: >> Kamil Dudka wrote: >>> I think we should improve documentation a bit. It is not only about hard >>> links. Some people may also want to disable file capabilities >>> highlight

Re: Not sure how to best reply re: dir_colors situation

Michael Kerrisk wrote: > 2009/6/7 Pádraig Brady : >> >> So I guess the middle ground is best of "not enable by default", >> though that will require adding documentation for the option. >> That's probably best to add in the dir_colors man page which &g

Re: [PATCH] maint: use a wildcard to include all syntax check exceptions in dist

Jim Meyering wrote: > Pádraig Brady wrote: >> I noticed a couple of syntax check exception files >> missing from the distribution tarball. Specifically >> .x-sc_require_config_h_first and .x-sc_error_message_uppercase >> >> The attached patch changes things so we d

Re: [PATCH] maint: use a wildcard to include all syntax check exceptions in dist

Jim Meyering wrote: > Pádraig Brady wrote: > > ... >> +test "$$(($(VC_LIST) | sed -n '/^.x-sc_/p'; \ >> + sed -n "/^$$sce =[ ]*$$/,/[^\]$$/p"

Re: [PATCH] maint: use a wildcard to include all syntax check exceptions in dist

Eric Blake wrote: > Pádraig Brady draigBrady.com> writes: > >> Attached is a new syntax-check rule to ensure the list for >> distribution stays in sync with the repository. > > Can you please move this to gnulib's maint.mk, rather than coreutils cfg.mk, > as

Re: [PATCH] stdbuf work in progress

Latest iteration of stdbuf command. Notes: * It installs an unversioned shared lib to PKGLIBDIR (/usr/local/lib/coreutils by default). This is searched for by stdbuf itself rather than relying on the system, which allows us to select the uninstalled lib alongside the stdbuf binary whe

Re: [PATCH] stdbuf work in progress

Jim Meyering wrote: > Pádraig Brady wrote: >> Latest iteration of stdbuf command. >> >> Notes: >> * It installs an unversioned shared lib to PKGLIBDIR >>(/usr/local/lib/coreutils by default). This is searched >>for by stdbuf itself rather than relyi

Re: [PATCH] stdbuf work in progress

These 2 hunks are also required to stop check-AUTHORS causing a silent coredump and to no exclude libstdbuf.c from the sc_tight_scope check: diff --git a/src/Makefile.am b/src/Makefile.am index 85a3841..816ab80 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -405,6 +405,7 @@ check-AUTHORS: $

Re: make fails

Eric Blake wrote: > According to peter on 6/9/2009 10:47 AM: >>I run configure. It runs fine. I compile it, and every instance of >> a variable not declared at the beginning of a block produces a compiler >> error. I assume this is some recent modification to the C standard that >> is certai

Re: Sort by version number (patch included)

Ian Dall wrote: >Padraig Brady writes: > > Ian Dall wrote: > > > > >I needed to sort by version number so that 1.2.12 > 1.2.3 > > > > > >[...] > > > > > >2005-11-02 Ian Dall <[EMAIL PROTECTED]> > > > > > > * coreutils.texi (sort invocation): Document new option > > > --version-sort (-v). >

Re: [patch #4600] Addition of "dups" file utility to GNU Core Utilities

anonymous wrote: >URL: > > > Summary: Addition of "dups" file utility to GNU Core > > Thanks, I'm not sure that's general enough for a coreutil. maybe? I'm not sure you're using the optimum algorithm. Have a look at h

Re: dd does not handle input from pipes correctly (coreutils-5.93)

Eric Blake wrote: > According to James Youngman on 11/18/2005 1:28 AM: > > >Many systems now include the 'buffer' program (I have it here on an > >Ubuntu box). If you have it, try piping the data through 'buffer -z > >4096' (or whatever PIPE_BUF is on your machine if it's not 4096). > > > Is it w

Re: du thousands grouping

Juha-Pekka Järvenpää wrote: > Hi, > > Just a feature request for du. > > I was just wondering if it would be possible for du to print out file > sizes with thousands grouped. > > Instead of: > > 5641356 dump.sql > > it could print something like > > 5 641 356 dump.sql > > You can't generally sort

<    1   2   3   4   5   6   7   8   9   10   >