Hi Pádraig, Thanks for your prompt response.
You guys may have your criterion for new features, here are my arguments: 1) Convenience and performance is what people need. Split and csplit exist when their functionality can mostly be realized by grep, head, and tail repeatedly. 2) This request should be fairly easy to implement on top of the existing code. Will it hurt even if it is not a common use case? How many iPhone apps out of more than one million do people use? Hope you are 60:40 for implementing it :) Hong On Wed, Mar 12, 2014 at 4:22 AM, Pádraig Brady <[email protected]> wrote: > On 03/12/2014 04:26 AM, Hong Yang wrote: > > If a user is splitting a large file into pieces only to use several of > them, it will be efficient to just specify the indexes of files to output. > > > > Take an extreme case for example. "a_large_file" has 12823371193 lines. > "csplit a_large_file 823371193 823371293" will have three output files: > xx00 with 823371192 lines, xx01 with 100 lines, and xx02 with the rest. If > a user is only interested in xx01, it will be desirable to do "csplit > a_large_file 823371193 823371293 -o 1." > > So this is a borderline one. > > Functionally it is useful as it can avoid redundant > processing and storage. > > split(1) has a similar feature in that one can use -n K/N > to split the Kth item out of N. It doesn't support -o N, > to select an arbitrary chunk based on size, as that can be done > for single chunks with dd. > If we were to implement for csplit, we'd probably implement > for split also, and support specifying multiple (disjoint) chunks. > > However given it is only a performance feature and I'm thinking not > a common use case, I'm 60:40 against implementing it. > > thanks, > Pádraig. >
