Discussion:
echo command vs octal and hexadecimal formatting.
(too old to reply)
Elie De Brauwer
2012-02-11 14:12:07 UTC
Permalink
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.
--
Elie De Brauwer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: echo_octal_and_hexadecimal_input_fix_plus_testing.patch
Type: text/x-patch
Size: 2474 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120211/64886a56/attachment-0001.bin>
Rob Landley
2012-02-11 19:17:45 UTC
Permalink
Post by Elie De Brauwer
Hello all,
- 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
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
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
Rob Landley
2012-02-11 19:26:32 UTC
Permalink
Post by Elie De Brauwer
- I added a small test, testing several corner cases of the hex and
octal formatting.
my 2 cents
E.
And scripts/config2help.py is expanding spaces to tabs anyway so it's
currently a moot point. Sigh.

(I'm halfway through rewriting it in C, at which point I need to write a
documentation web page specifically on the help stuff, and how I want
each help entry's leading "usage: " line to get merged into one when you
select suboptions that need their help entries stitched together.)

But that's a todo item for after the release...

Rob
Rob Landley
2012-02-11 19:28:13 UTC
Permalink
Post by Elie De Brauwer
Hello all,
- 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).
I.E. it's a Linux extension, but a reasonable one.

My default is to support all posix behavior and not support any
nonstandard behavior, but there are lots of exceptions in both
directions. (The bar for deviating from the default isn't that high, it
just means "think about it before doing it".)

Rob
Elie De Brauwer
2012-02-11 14:12:07 UTC
Permalink
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.
--
Elie De Brauwer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: echo_octal_and_hexadecimal_input_fix_plus_testing.patch
Type: text/x-patch
Size: 2474 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120211/64886a56/attachment-0002.bin>
Rob Landley
2012-02-11 19:17:45 UTC
Permalink
Post by Elie De Brauwer
Hello all,
- 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
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
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
Rob Landley
2012-02-11 19:26:32 UTC
Permalink
Post by Elie De Brauwer
- I added a small test, testing several corner cases of the hex and
octal formatting.
my 2 cents
E.
And scripts/config2help.py is expanding spaces to tabs anyway so it's
currently a moot point. Sigh.

(I'm halfway through rewriting it in C, at which point I need to write a
documentation web page specifically on the help stuff, and how I want
each help entry's leading "usage: " line to get merged into one when you
select suboptions that need their help entries stitched together.)

But that's a todo item for after the release...

Rob
Rob Landley
2012-02-11 19:28:13 UTC
Permalink
Post by Elie De Brauwer
Hello all,
- 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).
I.E. it's a Linux extension, but a reasonable one.

My default is to support all posix behavior and not support any
nonstandard behavior, but there are lots of exceptions in both
directions. (The bar for deviating from the default isn't that high, it
just means "think about it before doing it".)

Rob

Loading...