Re: base85 would it be accepted

[Eric Curtin]

On 20 November 2017 at 20:02, L A Walsh <address@hidden> wrote:
> Pádraig Brady wrote:
>>
>> On 13/10/17 03:28, Eric Curtin wrote:
>>
>>>
>>> Hi Guys,
>>>
>>> I find base32 and base64 very useful in coreutils. If I wrote a base85
>>> implementation in the same style would it be accepted? Just wondering,
>>> don't want to waste my time submitting just in case.
>>>
>>
>>
>> Well as the bit width increases there is more opportunity
>> for application specific variations on the encoding.
>> I quick check confirms this, so I'm thinking that base85
>> is more useful as an application specific encoding used
>> by pdf or git etc. rather than a standalone useful encoding/util.
>>
>
> ----
>    I know this is a bit of an old topic, but nevertheless,
> might be useful...
>
>   If the utility was a "baseN" utility to allow arbitrary
> N, up to, maybe, N=96 (0x20-0x7f -- printable characters or
> *maybe*, N=95 if space was not usable for encoding (though
> I don't see why it wouldn't), WITH the ability to read
> the invoking filename to look for baseXX, and use a number
> after 'base' as the default encoding base, then such a utility
> might replace base32 and base64 (by eliminating the need for
> special cases) and would seem to provide a more maintainable
> single-source for bases 32 & 64, while also providing the ability
> to make a link from base85->basnN, that would also implement
> the feature Eric wants.
>
>    Wouldn't that be a useful way for Eric to get what he wants,
> while providing better maintenance for 32 & 64 by eliminating the
> need for separate progs for each?
>
> -l
>
>
>

Sounds like a good idea to me, but I worry a little about removing the
separate progs for base32 & base64 , fearing that would break scripts
that use them. Although in that case I guess we could replace base32
and base64 binaries with scripts/binaries that call the new base binary
like follows `base 32` and `base 64`.