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 mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org
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 @@ scan_arg
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 as EXIT_FAILURE is being invoked?
Steven Schubiger
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 Schubiger [EMAIL PROTECTED
-printf
resembling behavior).
Steven Schubiger
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
.
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;
+static bool print_formatted_line;
+
+#define FORMAT_TYPES_NUM
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 stdout.
+ * src/split.c
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_file_flag, const char *bp, size_t
bytes
more light?
Steven Schubiger
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
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:
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 if we can be consistent about
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
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
(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
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.
Steven Schubiger
diff --git a/src/df.c b
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 customized code.
Steven Schubiger
___
Bug
||
causes trouble here. I'm 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
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 effort).
Steven
: 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
, 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
- 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:
Jim Meyering [EMAIL PROTECTED] wrote
of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME linecut
#define AUTHORS Steven Schubiger
/* Maximum of allowed range sets. */
#define MAX_RANGE_SETS (4 * 2)
/* Macro for validation of range components. */
#define VALID_RANGE(range) (ISDIGIT (range) || range == '-' || range
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
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_ work
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 two
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 '-' '+'
prefixes would
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 mean
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 agree
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 lines
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 extract the
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 different
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
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 file
$ linecut --range 10,-10 --number file
$ linecut --range 15,15:18,18 --number
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 solely
-- 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:
On 7 Apr, G
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
36 matches
Mail list logo
