Re: base85 would it be accepted

[L A Walsh]

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.