Re: Not a bug, a wish

via https://savannah.nongnu.org/projects/linecut . Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

[RFC] seq: allow format string to contain no %-directives

uld we perhaps circumvent this limitation whenever an alphanumeric string is found? PS: I searched the mailing list archive, but there didn't seem to be any previously related discussion on this topic. Steven Schubiger ___ Bug-coreutils mail

Re: [PATCH] better diagnostics for seq

tation for seq with regard to diagnostics (as expected). FYI, make distcheck ungracefully exits with "fuzzy patch". Steven Schubiger diff --git a/ChangeLog-2008 b/ChangeLog-2008 index aac9feb..df88058 100644 --- a/ChangeLog-2008 +++ b/ChangeLog-2008 @@ -1,3 +1,13 @@ +2008-02-18 Steven

Re: [PATCH] better diagnostics for seq

gt; Try `seq --help' for more information. > > So perhaps you could use the existing patch/logic from gutsy? FWIW, with the patched version I get: $ ./src/seq -f% 1 ./src/seq: no % directive Should we be additionally calling usage (EXIT_FAILURE); where now error() with first argument

[PATCH] better diagnostics for seq

Attached is a patch that enhances seq's diagnostics. If you agree that this is the right way to go, I'll amend other files (ChangeLog, etc.) as needed. Steven Schubiger diff --git a/src/seq.c b/src/seq.c index 261a44b..4a6f96e 100644 --- a/src/seq.c +++ b/src/seq.c @@ -185,12 +185,38 @

Re: [RFC]: --format=FORMAT option for ls

is needed (unless we want a working find -printf resembling behavior). Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

[RFC]: --format=FORMAT option for ls

lete at all, but merely an approximation. Ideas, opinions and critique are welcome. Steven Schubiger diff --git a/src/ls.c b/src/ls.c index 46713f2..b15042b 100644 --- a/src/ls.c +++ b/src/ls.c @@ -584,6 +584,12 @@ static bool immediate_dirs; static bool directories_first; +stat

[PATCH] mkdir/split: send --verbose output to stdout

FWIW, "make distcheck" still fails... Steven Schubiger diff --git a/ChangeLog b/ChangeLog index 62c7930..459aa46 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2008-02-01 Steven Schubiger <[EMAIL PROTECTED]> + + * src/mkdir.c: Send --verbose output to stdou

Re: [PATCH] split: --verbose output to stdout

Jim Meyering <[EMAIL PROTECTED]> wrote: > Steven Schubiger <[EMAIL PROTECTED]> wrote: > > diff --git a/src/split.c b/src/split.c > > index 5807a1c..2ad0baf 100644 > > --- a/src/split.c > > +++ b/src/split.c > > @@ -208,7 +208,7 @@ cwrite (bool new

Re: wc -l is not working the way it should

r" with wc as of version 5.97 (coreutils). Can someone else shed some more light? Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

[bug #22017] zic can generate files which crash the linux kernel

Follow-up Comment #1, bug #22017 (project coreutils): zic is not part of coreutils, but does belong to the GNU C library (glibc). See http://www.gnu.org/software/libc/bugs.html for bug report instructions. ___ Reply to this item at:

[PATCH] split: --verbose output to stdout

Patch attached (tested). Steven Schubiger diff --git a/src/split.c b/src/split.c index 5807a1c..2ad0baf 100644 --- a/src/split.c +++ b/src/split.c @@ -208,7 +208,7 @@ cwrite (bool new_file_flag, const char *bp, size_t bytes) next_file_name (); if (verbose) - fprintf (stderr

Re: [RFC] shred: --verbose output to stdout

Jim Meyering <[EMAIL PROTECTED]> wrote: > shred uses stdout when FILE is "-", so its verbose output > must continue to go to stderr. TODO patch attached. Steven Schubiger diff --git a/TODO b/TODO index 473eeca..b7e8a69 100644 --- a/TODO +++ b/TODO @@ -43,6 +43,8 @@ See i

[RFC] shred: --verbose output to stdout

equired that 3 non-fatal calls to error() are to be replaced with calls to output(). It is also questionable whether the code should reside in some library and thus may also be used by mkdir and split or whether each program has its own piece of cust

Re: [PATCH] df: add `--total' option

Jim Meyering <[EMAIL PROTECTED]> wrote: > Thanks for the patch. FTR (for the record), a second version which does some "magic" to obtain the block-size argument and append it to the output. I don't think, it'll be of much use now, but archiving doesn't hurt.

Re: [PATCH] df: add `--total' option

patches within the TODO (and perhaps provide a link)? I think, this could reduce some duplicated effort. Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] df: add `--total' option

I'm not adding features like that until after > the release of a stable coreutils-6.10. Sure. Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

[PATCH] df: add `--total' option

Given that the attached patch works, except that the SIZE argument specified to -B/--block-size parameter doesn't currently make it into the totals, I'd like to hear some opinions how you would make it happen (I have some ideas, but I'd certainly prefer to have some peer- driven e

bootstrapping fails with git v1.4.4.4

not sure whether I should update git or if this feature has been deprecated and removed from the git toolsuite. Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: linecut (further refinement)

ible implementation) ? I do, but if you (i.e., this list) can't be convinced, I won't pursue this any further. Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

linecut (further refinement)

ug : no fpu : yes fpu_exception : yes cpuid level : 2 wp: yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips : 799.53 Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Fwd: Re: linecut (warnocked?)

- Forwarded message from Jim Meyering <[EMAIL PROTECTED]> - Date: Fri, 19 Oct 2007 23:50:58 +0200 From: Jim Meyering <[EMAIL PROTECTED]> To: Steven Schubiger <[EMAIL PROTECTED]> Subject: Re: linecut (warnocked?) Steven Schubiger <[EMAIL PROTECTED]> wrote:

Re: linecut development

ot; #include "error.h" #include "quote.h" #include "safe-read.h" /* The official name of this program (e.g., no `g' prefix). */ #define PROGRAM_NAME "linecut" #define AUTHORS "Steven Schubiger" /* Maximum of allowed range sets. */ #de

linecut development

Since no one explicitly rejected the idea of adding linecut to coreutils, I've re-implemented quite a bit of functionality to suit the requirements of a coreutils tool (see previous mail for enlistment). I'm currently struggling how to make pipe support work correctly, because one needs to know be

Re: [RFC] linecut addition

Jim Meyering <[EMAIL PROTECTED]> wrote: > I don't want to dissuade you from writing the tool, [...] Status quo: I've edited the local Makefile.am within src/ and the make process works fine. Most of the functionality has been rewritten, albeit it should function equally. Things that _should_ wo

Re: [RFC] linecut addition

Matthew Woehlke <[EMAIL PROTECTED]> wrote: > >I fail to see where your descriptions don't apply to the current > >working mechanism (implying that I eventually don't fully grok your > >wording). > > Probably, because... > > [...] > > ...you obviously feel that '+0' means 'output no lines' and th

Re: [RFC] linecut addition

Matthew Woehlke <[EMAIL PROTECTED]> wrote: > Disallowing it is fine, but if you disallow it, it seems reasonable to > expect the program to say that it was disallowed :-). (I'm on the fence > if this counts as a specification or implementation detail.) The more specification details we can agre

Re: [RFC] linecut addition

Matthew Woehlke <[EMAIL PROTECTED]> wrote: > Well, yes, I would hope so. If you can't write 'a + b' in your program, > something is wrong ;-). (Use case is of course e.g. scripts where the > beginning line is not known in advance, but you know you want N lines > total.) Am I right assuming you

Re: [RFC] linecut addition

Matthew Woehlke <[EMAIL PROTECTED]> wrote: > Do you plan to have a means of specifying a number of lines? E.g.: > > $ seq 10 | linecut --range 5,+3 > 5 > 6 > 7 I like the idea. And it should be rather easy to calculate the ending line position. I hope the distinction between the '-' & '+' "prefi

Re: [RFC] linecut addition

Jim Meyering <[EMAIL PROTECTED]> wrote: > That's a good start, but please elaborate on the following, too: > > What if ranges overlap? > I.e., --range 1,5:4,8 $ seq 10 | linecut --range 1,5:4,8 1 2 3 4 5 4 5 6 7 8 > Bear in mind that with an EOF-relative endpoint, > we can't even know whether t

Re: [RFC] linecut addition

Jim Meyering <[EMAIL PROTECTED]> wrote: > Before coding further, I strongly urge you to nail down the > specification -- publicly. Put it this way: write enough > details that someone reading your description in a man page > would not be disappointed. DESCRIPTION linecut extracts slices of line

Re: [RFC] linecut addition

Jim Meyering <[EMAIL PROTECTED]> wrote: > Your range_lines function reads only one buffer's worth of data. Uhm, yes. I noticed it later on. > While I did mention head, above, a subsequent message pointed > to tail as a better source of relevant code: > > >> However, another possibility is to ext

Re: bugs in program "head" and maybe "tail"

On Fri, Sep 14, 2007 at 03:45:14PM +0200, julien wrote: > $ man -t ls > ls.ps && ps2pdf ls.ps && rm ls.ps > $ head ls.pdf > > the caracteres are strange ! This is not a bug. head shouldn't be used on binary streams, it is intented to be used for ASCII streams only. __

Re: [RFC] linecut addition

>From a conversation with Jim: On Fri, Aug 24, 2007 at 02:27:34PM +0200, Jim Meyering wrote: > If you end up adding a program to coreutils, > it may make more sense to add a tiny bit of code to "head", > to make it work the way you want, and then to arrange for that code > to be enabled in a diffe

Re: [RFC] linecut addition

On Mon, Aug 27, 2007 at 10:04:57AM +0100, Pádraig Brady wrote: > I think this (rarely used) functionality is > adequately provided by existing tools: > > cat -n | sed -n '1,10p;50,80p;80q' Not so sure, but sed doesn't allow for line offsets relative from the end, nor does it work on multiple fi

Re: [RFC] linecut addition

On Sun, Aug 26, 2007 at 09:07:34AM -0600, Bob Proulx wrote: > Looking at this briefly this looks to be very similar to actions > provided by sed, head and tail. Could you describe features in > linecut that are not present there? An introductory word: linecut was specifically designed with sole

[RFC] linecut addition

I've written a small utility that does easily extract line slices. It has currently one convenience switch "-n", which triggers numbered output. Sample invocations: $ linecut --range 1,10:50,80:-200,-1 --number $ linecut --range 10,-10 --number $ linecut --range 15,15:18,18 --number Likew

Fwd: Re: extend rm docs (was: slight 'rm --help' confusion)

-- Forwarded message -- From: Geoffrey Odhner <[EMAIL PROTECTED]> Subject: Re: extend rm docs (was: slight 'rm --help' confusion) Date: Fri, 8 Apr 2005 21:23:53 -0400 To: [EMAIL PROTECTED] On Thu, 7 Apr 2005 20:01:24 +0200 (CEST) Steven Schubiger wrote:

Re: extend rm docs (was: slight 'rm --help' confusion)

On 7 Apr, G. Vamsee Krishna wrote: : Would be nice though if it says that `rm' does the same thing to : directories too. I still remember using `rmdir' on an empty directory : about 2 years ago when I started using GNU/Linux. Could we have some more opiniated input on this issue by others? If