On 20 November 2017 at 20:02, L A Walsh <[email protected]> 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`.
