[EMAIL PROTECTED] wrote:
...
> I am aware that if I change the final token from '2' to '{2}' that
> 4 files will be created without error. However, I think the parsing
> mechanism should be sufficiently robust to accommodate the omission
> of the braces. Moreover, non-GNU versions of CSPLIT work without
> the curly braces, so this syntax should be supported, IMO.
...
> [1] d:\temp\erasenow>>csplit file "/^$/" 2
> 95
> Assertion failed at csplit.c line 779: (linenum == 1 && last_line_to_save == 1)
> || linenum < last_line_to_save
> Exiting due to signal SIGABRT
Thanks a lot for the report.
That was a very old bug. From more than 9 years ago.
I've fixed it by removing the assertion altogether.
`2' or `{2}' mean different things in that context,
so csplit shouldn't interpret the former as the latter:
`2' refers to the second line.
`{2}' tells csplit to repeat the preceding pattern that many times
Here's an excerpt the documentation in `info csplit':
-------------------
csplit [OPTION]... INPUT PATTERN...
The contents of the output files are determined by the PATTERN
arguments, as detailed below. An error occurs if a PATTERN argument
refers to a nonexistent line of the input file (e.g., if no remaining
line matches a given regular expression). After every PATTERN has been
matched, any remaining input is copied into one last output file.
By default, `csplit' prints the number of bytes written to each
output file after it has been created.
The types of pattern arguments are:
`N'
Create an output file containing the input up to but not including
line N (a positive integer). If followed by a repeat count, also
create an output file containing the next LINE lines of the input
file once for each repeat.
`/REGEXP/[OFFSET]'
Create an output file containing the current line up to (but not
including) the next line of the input file that contains a match
for REGEXP. The optional OFFSET is a `+' or `-' followed by a
positive integer. If it is given, the input up to the matching
line plus or minus OFFSET is put into the output file, and the
line after that begins the next section of input.
_______________________________________________
Bug-textutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-textutils
