Post by Elie De Brauwer
- echo -e has support for octal in the code but the help does not show
- since octal gives me headaches (i know, it's an acquired taste) and
my cksum unittest (see previous e-mail) made use of echo \x I've added
support for hexadecimal characters in echo (if the cksum ever use the
supplied echo command this would expose itself). Even though the
opengroup page doesn't explicitly list support for \x (but man echo on
my box does).
- the \0 parsing code shows a bug, if you would in the current code do
echo -e "\01160000" the output should be "N0000" but in the current code
the conversion would eat up all the 0's and cause overflows and funky
things in the final result.
- I added a small test, testing several corner cases of the hex and
my 2 cents
Looks mostly good.
The help text change:
The "obvious to explain" bit is that I used a single tab after each -X
instead of ~4 spaces to keep the binary size down. Saves about 3 bytes
The "hard to explain" bit is the leading whitespace.
The horrible mix of tabs and spaces in the leading whitespace actually
has a reason: because leading whitespace on help entries is significant
(bordering on magic) for the kconfig infrastructure, as described in
Post by Elie De Brauwer
- help text: "help" or "---help---"
This defines a help text. The end of the help text is determined by
the indentation level, this means it ends at the first line which has
a smaller indentation than the first line of the help text.
So all the previous config lines were indented by one tab (including the
"help" keyword line), and then I indented two more spaces from that to
start the help text. (Because I wanted it to be visually indented but
another tab would eat too much of an 80 column screen and make the help
text a bit squished; especially since it was _displayed_ with a full 80
columns by the help command, but going past column 80 in the source
Yeah, I'm mixing tabs and spaces, it's horrible and I'm open to
suggestions on a better way to do it...
My config2help script strips an amount of leading space equal to the
amount the first line of help text had, and actually does it via
strncmp() so it cares that it has the same mix of tabs and spaces. The
_advantage_ of doing this is you can stick arbitrary extra whitespace on
past that point if you want to indent lines in the help entry and have
the help command display that indent.
But yeah, it's ugly.
Alas, "leveraging how kconfig works" means "unavoidably subtle", because
the way kconfig treats help text is already subtle. (I found this out
writing the config2html converter to produce
http://kernel.org/doc/menuconfig/ .) I hope to replace the kconfig
infrastructure with a fresh implementation, but it'll probably still be
compatible with the kconfig _language_ definition, since there is one.
And the "leading whitespace on help entries is sort of magic" is part of
(This is why when I saw whitespace-only change in the help text entries,
I said "oh dear" out loud over here. Usually when something needs this
much explanation I just want to rip it out, but doing so would break
compatability with the kconfig language. Not sure how to clean that up