bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.

[Jérémy Compostella]

Thanks to both you for looking at this patch.

I'm a bit busy right now. I will take your proposition into account as soon
as possible. Exceptionaly, I do not have access to a computer during the
day this week. I only have access to my mailbox via my phone.

Cheers,

Jeremy
Le 30 janv. 2012 12:07, "Jim Meyering" <address@hidden> a écrit :

> Pádraig Brady wrote:
> > On 01/30/2012 10:29 AM, Pádraig Brady wrote:
> >> On 01/29/2012 10:34 PM, Jérémy Compostella wrote:
> >>> Pádraig, Sci-Fi, others,
> >>>
> >>> I made an implementation of the requested feature. With the attached
> >>> patch applied the split command accepts a new optional "from" argument
> >>> for the --numeric-suffixes (aka -d) option. If this argument is
> >>> specified, the numeric suffix counts from this value, otherwise, like
> >>> before, it counts from 0.
> >>>
> >>> I've tried to not impact the performance, to not break anything and to
> >>> respect the coding rules but feel free to comment this patch. I will
> >>> take into account whatever you may want.
> >>
> >> Thanks again for looking at this.
> >> It's a useful feature for the presented use case,
> >> or for supporting multiple independent split invocations.
> >>
> >> Note we rarely change an option to have optional args.
> >> For optional args, no space is allowed between option name and value.
> >> I.E. --numeric-suffixes=10 or -d10 is required, which is a little
> restrictive.
> >> More problematically though, existing scripts using the short
> >> options -de or -du in
> >> combination will break.  The -eu options are relatively new though,
> >> so I'm leaning
> >> towards this being acceptable. Hmm, this unusual form would fail
> >> too, `split -da3 ...`.
> >> The failure mode is immediate and obvious, but this worries me a bit.
> >>
> >> I wonder might we have a separate option, --suffix-start,
> >> and theoretically that could accept alphabetic options too?
> >> I'm not suggesting we do this, but it's worth discussing.
> >
> > Think a bit more about it, it's probably worth to split
> > the short and long options. Have -d not take a param as before,
> > and have --numeric-suffixes take an optional param.
>
> I agree.
> We try hard to avoid short options with optional args
> for the reasons you've outlined above.
>