GNU bug report logs -
#6554
[coreutils] Additional suffix for split
Previous Next
Reported by: Eric Blake <eblake <at> redhat.com>
Date: Fri, 2 Jul 2010 19:53:02 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
Message #20 received at 6554 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 13 years and 95 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.