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.
