[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jim Meyering
Subject: bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
Date: Mon, 30 Jan 2012 12:07:23 +0100

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]