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
Steven Schubiger wrote:
Would `linecut --range 1:2,3:4,-100:-1` be considered sensible?
Do you plan to have a means of specifying a number of lines? E.g.:
$ seq 10 | linecut --range 5,+3
5
6
7
$
@Jim, 'addr1,addr2' syntax belongs to sed, so I would argue it isn't
new. It's also easier to
Matthew Woehlke [EMAIL PROTECTED] wrote:
Steven Schubiger wrote:
Would `linecut --range 1:2,3:4,-100:-1` be considered sensible?
Do you plan to have a means of specifying a number of lines? E.g.:
$ seq 10 | linecut --range 5,+3
5
6
7
$
@Jim, 'addr1,addr2' syntax belongs to sed, so I
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
Jim Meyering wrote:
Matthew Woehlke mw_triad.NO.SPAM.PLEASE wrote:
@Jim, 'addr1,addr2' syntax belongs to sed, so I would argue it isn't
new. It's also easier to type when specifying only one range :-).
Sure, but sed doesn't have the notion of a *sequence* of ranges,
so it doesn't have to
Steven Schubiger wrote:
Matthew Woehlke mw_triad.NO.SPAM.PLEASE 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.
Well, yes, I would hope so.
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
Steven Schubiger wrote:
Matthew Woehlke 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
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
Steven Schubiger [EMAIL PROTECTED] wrote:
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.
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
Steven Schubiger [EMAIL PROTECTED] wrote:
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
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
Steven Schubiger wrote:
I've written a small utility that does easily extract line slices.
...
I'm here to collect opinions suggestions, so feel free to reject the idea.
Looking at this briefly this looks to be very similar to actions
provided by sed, head and tail. Could you describe
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
19 matches
Mail list logo
