[Toybox] echo command vs octal and hexadecimal formatting.

[Rob Landley]

On 02/11/2012 08:12 AM, Elie De Brauwer wrote:
> Hello all,
> 
> In attachment a patch which addresses several points:
>  - echo -e has support for octal in the code but the help does not show
> this.
>  - 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
> octal formatting.
> 
> my 2 cents
> E.

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
each.

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
http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt

>- 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
looks ugly.)

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
that...

(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
yet...)

Rob