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

[Jérémy Compostella]

On 01/28/2012 00:00 AM, Pádraig Brady wrote:
> On 01/28/2012 11:57 PM, Jérémy Compostella wrote:
[...]
> >> 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.
Thanks, I get it now. IMHO these options should not be mutual exclusives
but the documentation should mention the variable length dynamic suffix
algorithm and warn about this behavior. In that case the user will be
able to have the precise behavior he wants without a systematic
constraint.

> >> 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.

Jeremy