Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: > Pádraig Brady <[EMAIL PROTECTED]> wrote: >> Jim Meyering wrote: What about adding buffer control to all coretuils filters. Is that still a desired feature do you think? >>> I don't relish the idea of adding an option or feature >>> to each and every filter in coreuti

Re: Possible bug with grep/sed/tail?

Paolo Bonzini <[EMAIL PROTECTED]> wrote: >> So -ol (that's an el) would mean line-buffered stdout? >> That has to be equivalent to -o -l, and unless you consider >> ordering and multiple -l options (e.g., "-i -l -o -l" is ugly), >> then it doesn't let you line-buffer more than one of the three stre

Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: > Pádraig Brady <[EMAIL PROTECTED]> wrote: >> >> I'm now thinking of 3 options: stdbuf -i -o -e >> The usual use case is: stdbuf -ol >> But you could also do: stdbuf -i4096 -o8192 >> We would warn about redundant combos like: stdbuf -il > > So -ol (that's an el) would mean line

Re: Possible bug with grep/sed/tail?

Paolo Bonzini wrote: > Jim Meyering wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> wrote: So -ol (that's an el) would mean line-buffered stdout? That has to be equivalent to -o -l, and unless you consider ordering and multiple -l options (e.g., "-i -l -o -l" is ugly), then it doesn

Re: Possible bug with grep/sed/tail?

Pádraig Brady <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Pádraig Brady <[EMAIL PROTECTED]> wrote: >>> >>> I'm now thinking of 3 options: stdbuf -i -o -e >>> The usual use case is: stdbuf -ol >>> But you could also do: stdbuf -i4096 -o8192 >>> We would warn about redundant combos like: stdb

Re: Possible bug with grep/sed/tail?

Pádraig Brady <[EMAIL PROTECTED]> wrote: ... >>> tail -f access.log | stdbuf --fd=1 --size=1 cut -d' ' -f1 | uniq >>> >>> size=0 => unbuffered >>> size=1 => line buffered >>> size>1 -> specific buffer size >>> >>> Also we could have aliases for stdin stdout, linebuffered, ... >>> >>> We still have

Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: > Paolo Bonzini <[EMAIL PROTECTED]> wrote: >>> So -ol (that's an el) would mean line-buffered stdout? >>> That has to be equivalent to -o -l, and unless you consider >>> ordering and multiple -l options (e.g., "-i -l -o -l" is ugly), >>> then it doesn't let you line-buffer more

Re: Possible bug with grep/sed/tail?

> So -ol (that's an el) would mean line-buffered stdout? > That has to be equivalent to -o -l, and unless you consider > ordering and multiple -l options (e.g., "-i -l -o -l" is ugly), > then it doesn't let you line-buffer more than one of the three streams. It would be "+i::o::e::" in getopt par

Re: "du -b --files0-from=-" running out of memory

Jim Meyering <[EMAIL PROTECTED]> wrote: > Eric Blake <[EMAIL PROTECTED]> wrote: >> According to Barry Kelly on 11/23/2008 6:24 AM: >>> I have a problem with du running out of memory. >>> >>> I'm feeding it a list of null-separated file names via standard input, >>> to a command-line that looks like

Re: "du -b --files0-from=-" running out of memory

Jim Meyering wrote: > Subject: [PATCH 1/2] argv-iter: new module > > * gl/lib/argv-iter.h: New file. > * gl/lib/argv-iter.c: New file. > * gl/modules/argv-iter: New file. Very useful module! I see that --files0-from was added to `du` in Mar 2004, so it's a nice solution to this 4 year old issue.

Re: "du -b --files0-from=-" running out of memory

Pádraig Brady <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Subject: [PATCH 1/2] argv-iter: new module >> >> * gl/lib/argv-iter.h: New file. >> * gl/lib/argv-iter.c: New file. >> * gl/modules/argv-iter: New file. > > Very useful module! > > I see that --files0-from was added to `du` in Mar 20

Re: "du -b --files0-from=-" running out of memory

Jim Meyering wrote: > Pádraig Brady <[EMAIL PROTECTED]> wrote: >> Jim Meyering wrote: >>> Subject: [PATCH 1/2] argv-iter: new module >>> >>> * gl/lib/argv-iter.h: New file. >>> * gl/lib/argv-iter.c: New file. >>> * gl/modules/argv-iter: New file. >> Very useful module! >> >> I see that --files0-fro

Re: "du -b --files0-from=-" running out of memory

Pádraig Brady <[EMAIL PROTECTED]> wrote: >>> I notice that argv_iter does a malloc() + memcpy() per entry. >>> Since the sources are already NUL terminated strings >>> perhaps it could just return a pointer to a getdelim >>> realloc'd buffer which was referenced in the argv_iterator struct. >> >> T

[bug #24934] confusing description of -c option

URL: Summary: confusing description of -c option Project: GNU Core Utilities Submitted by: None Submitted on: Tue 25 Nov 2008 11:38:19 PM UTC Category: None Severity:

[bug #24935] incorrect information regardin size suffixes in -c option

URL: Summary: incorrect information regardin size suffixes in -c option Project: GNU Core Utilities Submitted by: None Submitted on: Tue 25 Nov 2008 11:46:55 PM UTC Category: None

bug report

ran ./configure on coreutils 6.12 and got the following configure: WARNING: sys/wait.h: present but cannot be compiled configure: WARNING: sys/wait.h: check for missing prerequisite headers? configure: WARNING: sys/wait.h: see the Autoconf documentation configure: WARNING: sys/wait.h: sect

Re: [PATCH]: ls: add --user-format option for user defined format

Hey, just chiming in, since Jim alerted me to this thread after I recently filed http://bugs.debian.org/505979. I think, printf-like functionality would be very useful to have for very much the same reasons quoted in this thread, so I won't repeat them here. The issue Jim raises -- bloat -- is su

Re: bug report

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Gordon, John (SAIC) (c) on 11/25/2008 12:58 PM: > ran ./configure on coreutils 6.12 and got the following > > configure: WARNING: sys/wait.h: present but cannot be compiled > configure: WARNING: sys/wait.h: check for missing prerequis

sys/wait on Solaris (was: bug report)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Please keep the list in the loop; also, a more descriptive subject is helpful] According to Gordon, John (SAIC) (c) on 11/25/2008 7:43 PM: > it's a Sparc Solaris 10. > if you need specifics, send me the commands you want me to run. > i'll look for th

what a pitiful explanation for sha1sum

_ Access your email online and on the go with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access_112008___ Bug-coreutils mailing list Bug-cor

Re: what a pitiful explanation for sha1sum

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to landon kelsey on 11/25/2008 9:30 PM: > > Thanks for the report, I guess. Unfortunately, the body of your message is blank, and the subject doesn't quite tell us what you think is wrong with sha1sum. Would you care to elaborate? - --