On 21 November 2017 at 11:01, L A Walsh <[email protected]> wrote: > > > Eric Curtin wrote: >> >> On 20 November 2017 at 20:02, L A Walsh <[email protected]> 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!
