bug#6554: [PATCH] split: Additional suffix for split (bug#6554)

[Pádraig Brady]

On 01/28/2012 11:57 PM, Jérémy Compostella wrote:
>  Pádraig Brady wrotes:
>> Thanks a lot for working on this.
> 
>> Could you give a real world example where
>> you find this useful, just for the record.
> It's useful in some cases where the chunk files type is known. As for
> example, when I split a file which is a concatenation of several bitmap
> files of the same size. Automatically append the appropriate suffix
> "type" is time saving and comfortable. Another example is when the split
> does not alter the file "type" as in the example you provided below,
> input and output files are "txt" files. Having the appropriate suffix
> automatically appended to the chunk file names make these files easily
> available to applications which care about the file suffix.

Right, thanks for the clarification.

>> I should note that --suffix is incompatible
>> with a variable length generated suffix.
>> I.E. one that would allow for arbitrary sized input:
>> http://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00220.html
>> Though I guess that functionality could still be
>> provided if required, by specifying --suffix-length=auto
>> and having that mutually exclusive with --suffix.
> First, after having carefully read the thread you are talking about I
> did not find any implementation of this in the current coreutils
> repository. Anyway, this feature is interesting and I would be glad to
> implement it if needs too but in another commit.

Yes, this feature was removed from coreutils.
Anyway something to worry about later.

> Second, I don't get your point. Why it should not be possible to append
> a fixed length suffix to output files with a variable length dynamic
> suffix ? I do not figure out why it's incompatible. What do I
> misunderstood ?

To allow processing the split files in order.
If the supplied suffix is overlapping part of a generated suffix,
then there is no way to subsequently sort the parts.

> For example, the following hypothetical split command call looks
> perfectly compatible:
> $ split -b10 --suffix-length=auto --suffix=.txt file.txt file.
> $ ls
>   file.aa.txt
>   [...]
>   file.yz.txt
>   file.zaaa.txt

This example is usually OK as '.' will sort before letters.
If one has a --suffix without a '.' though, then we've problems.
This is just an edge case worth noting.

>> As for the patch, it seems to work :)
>>
>> t$ seq 10 > file.txt
>> t$ ../split -n10 --suffix=.txt file.txt file.
>> t$ l
>> -rw-rw-r--. 1 padraig 21 Jan 28 14:06 file.txt
>> -rw-rw-r--. 1 padraig  3 Jan 28 14:06 file.aj.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.ai.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.ah.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.ag.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.af.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.ae.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.ad.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.ac.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.ab.txt
>> -rw-rw-r--. 1 padraig  2 Jan 28 14:06 file.aa.txt
> 
>> We'd need some corresponding documentation in doc/coreutils.texi,
>> and an entry in NEWS.
> I added the corresponding documentation in both of files. I've done my
> best but feel free to comment my additions.
> 
>> Also even thought the patch is small, you'd need to start
>> the copyright assignment process for a new parameter to `split`.
> I filled out and sent my coreutils assignment form.

Excellent thanks.

Pádraig.