Re: base85 would it be accepted

[Eric Curtin]

On 21 November 2017 at 11:01, L A Walsh <address@hidden> wrote:
>
>
> Eric Curtin wrote:
>>
>> On 20 November 2017 at 20:02, L A Walsh <address@hidden> wrote:
>>>
>>>    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`.
>
> ---
>
>         The idea would be that both could be symlinks to
> 'baseN', which would  automatically generate the correct output
> for either tool.  There's no requirement that that the base32
> and base64 tools be removed, it's just that there "should" be no
> _need_ to keep the special-case programs.
>

Ah I see you explained that, read the invoking filename. Good idea!