Subject: bug#7241: closed (Re: bug#7241: Possible bug on split ?)

From: Ulf Zibis <[email-masked]>
Date: Thu, 02 Jun 2011 12:57:30 +0200

Am 01.06.2011 21:30, schrieb Jim Meyering:
> Ulf Zibis wrote:
>> You could write:
>>
>> `-b SIZE'
>> `--bytes=SIZE'
>>       Put SIZE bytes of INPUT into each output file.  SIZE may be, or
>>       may be an integer optionally followed by, one of the following
>>       multiplicative suffixes:
>>            `b'     =>              512 ("blocks")
>>            `KB'    =>             1000 (KiloBytes)
>>            `K'     =>             1024 (KibiBytes)
>>            `MB'    =>        1000*1000 (MegaBytes)
>>            `M','m' =>        1024*1024 (MebiBytes)
> Thanks, but I'd rather not encourage the use of "m", seeing as how
> it's irregular.  With no documentation, we have more flexibility, if
> we decide to deprecated it and eventually remove support for it some day.
> If we document it, that's an implicit endorsement and more of a
> commitment.
>
Maybe you could add a note:
(Note: for POSIX support lower 'm' is allowed for "MiB", but is not recommended)
(Note: In contradiction to SI, lower 'm' is allowed for "MiB" for POSIX support, but could become 
deprecated)

Then user would not try other lower letters if coming from FAQ tips like:
ntfsclone -s -o - <source> | gzip -c | split -a 3 -b 700m - <destination> ,
... and FAQ tip authors are aware to better use 'M'.

-Ulf

>>            `GB'    =>   1000*1000*1000 (GigaBytes)
>>            `G'     =>   1024*1024*1024 (GibiBytes)
>>       and so on for `T', `P', `E', `Z', and `Y'.
>>
>>
>> For split --help you could write (I only have the german version):
>>
>> GRÖßE kann eine der folgenden Abkürzungen sein (oder eine Zahl, die optional
>> von einer der Abkürzungen gefolgt wird):
>> KB 1000, K 1024, MB 1000x1000, M or m 1024x1024 und so weiter für G, T, P, E, Z, Y.
>
>
>