On 7/2/21 7:30 AM, Wolfgang Denk wrote:
Dear Tom,
In message <20210701202155.GQ9516@bill-the-cat> you wrote:
First, great! Thanks for doing this. A new shell really is the only
viable path forward here, and I appreciate you taking the time to
evaluate several and implement one.
I disagree that a new shell is the _only_ way forward.
AFAICT, all the raised concerns have long been fixed in upstream
versions of hush; see for example [1]:
...
//config: hush is a small shell. It handles the normal flow control
//config: constructs such as if/then/elif/else/fi, for/in/do/done, while
loops,
//config: case/esac. Redirections, here documents, $((arithmetic))
//config: and functions are supported.
//config:
[1] https://git.busybox.net/busybox/tree/shell/hush.c#n98
In fact, the code for most of this is present but ifdef'd out. The real
issue is that the implementation of much of the above relies on things
like fork() which we can't provide.
My gut feeling is that updating to a recent version of hush is the
most efficent _backward_compatible_ way.
And if we drop that requirement, we might even take a bigger step
and move to lua - which would allow for a complete new level of
script based extensions.
I'm not aware of any Lua implementations which meet the size
requirements for U-Boot. Any port would need to be either written from
scratch or have some serious modification, not unlike what I've done
here.
- There is a serious error handling problem. Most original LIL code never
checked errors. In almost every case, errors were silently ignored, even
malloc failures! While I have designed new code to handle errors properly,
there still remains a significant amount of original code which just ignores
errors. In particular, I would like to ensure that the following categories
of
error conditions are handled:
This is something that scares me like hell. This in a shell? For
me this is close to a killing point.
Yes, it was for me as well. But it is not something so obvious unless
you are looking for it. I believe I have addressed this issue in much of
the core code (parser and interpreter). But the builtin commands must be
gone through and converted.
- Running out of memory.
- Access to a nonexistant variable.
- Passing the wrong number of arguments to a function.
- Interpreting a value as the wrong type (e.g. "foo" should not have a
numeric
representation, instead of just being treated as 1).
Who says so?
The current LIL code.
Bash says:
-> printf "%d\n" foo
-bash: printf: foo: invalid number
0
So it is _not_ 1 ...
And I would like to replicate this behavior.
- There are many deviations from TCL with no purpose. For example, the list
indexing function is named "index" and not "lindex". It is perfectly fine to
drop features or change semantics to reduce code size, make parsing easier,
or make execution easier. But changing things for the sake of it should be
avoided.
It's not a standard POSIX shell, it's not TCL (ick!), ... it's
something new, incompatible...
And Hush isn't POSIX either :)
But as noted above, I would like to hew much closer to TCL than LIL has
traditionally done.
Thanks for the evaluations, of these, lil does make the most sense.
You mean, adding a complete new, incompatible and non-standard shell
is a better approach than updating to a recent version of hush?
Correct.
What makes you think so?
Hush relies heavily on its posix environment. Porting it has, and will,
require substantial modification. IMO the work necessary will be around
the same or more for Hush as for any other language.
--Sean
