More vis(3) options
Emmanuel Dreyfus
I often have to recode a base64 encoder/decoder or a hexdump routine.
What about adding VIS_BASE64STYLE and VIS_HEXDUMPSTYLE to vis(3)? These
two could even be reversed by unvis(3)
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@netbsd.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Jean-Yves Migeon
> I often have to recode a base64 encoder/decoder or a hexdump routine.
> What about adding VIS_BASE64STYLE and VIS_HEXDUMPSTYLE to vis(3)? These
> two could even be reversed by unvis(3)
I don't know about hexdump, but what about "openssl base64 [-d]" for
encoding/decoding base64?
Sure, this doesn't feel as convenient as extending vis(3), but at least,
you don't have to recode a base64 encoder/decoder.
--
Jean-Yves Migeon
jeanyve...@free.fr
John Nemeth
}
} I often have to recode a base64 encoder/decoder or a hexdump routine.
} What about adding VIS_BASE64STYLE and VIS_HEXDUMPSTYLE to vis(3)? These
} two could even be reversed by unvis(3)
This sounds like the perfect use for that "string codec" thing agc@
was talking about a while ago. Did that ever get committed?
}-- End of excerpt from Emmanuel Dreyfus
Alistair Crooks
> On Nov 29, 6:50am, Emmanuel Dreyfus wrote:
> }
> } What about adding VIS_BASE64STYLE and VIS_HEXDUMPSTYLE to vis(3)? These
> } two could even be reversed by unvis(3)
>
> was talking about a while ago. Did that ever get committed?
You're right, the codecs stuff was meant for exactly this. I didn't
think codecs sat well within the vis/unvis structure, mainly because
of the integer constant used to specify the transformation, which I
think was not scalable for what I wanted to do. Anyone familiar with
the python codecs should recognise the approach, too.
Other people had trouble with the way I implemented the codecs stuff -
in particular, some had trouble with using regular expressions to find
the correct translation to use, some with non-existent exit calls, and
others with the ways I used to cut down the number of translations
that were loaded.
In the end, I gave up - my intransigence to deal with it after 5
different proposals equalled the intransigence of the people who
didn't want it, and so I dropped the proposal. In hindsight, the
timing was wrong for me, personally, too.
In passing, I still feel that if someone proposes openssl as the
solution for anything, the pre-requisites that that brings in render
the solution too obscure to be realistic. If openssl were layered
better/at all, then things would be different.
Regards,
Alistair
Emmanuel Dreyfus
> I don't know about hexdump, but what about "openssl base64 [-d]" for
> encoding/decoding base64?
I meant using it from a C program: vis(3), not vis(1) :-)
> Sure, this doesn't feel as convenient as extending vis(3), but at least,
> you don't have to recode a base64 encoder/decoder.
The tradeoff is that you need to link with -lssl. I am not sure this
sounds reasonable for random programs that need to display binary
data.
--
Emmanuel Dreyfus
Thor Lancelot Simon
> On Sat, Jul 09, 2011 at 04:42:02PM +0200, Jean-Yves Migeon wrote:
> > I don't know about hexdump, but what about "openssl base64 [-d]" for
> > encoding/decoding base64?
>
> I meant using it from a C program: vis(3), not vis(1) :-)
I believe we already have what you need in libc, because the resolver
code uses it.
Thor
Emmanuel Dreyfus
> I believe we already have what you need in libc, because the resolver
> code uses it.
For base64, but what about hexdump?
--
Emmanuel Dreyfus