[RFC PATCH 00/28] cli: Add a new shell
Wolfgang Denk
wd at denx.de
Fri Jul 2 13:30:12 CEST 2021
Dear Tom,
In message <20210701202155.GQ9516 at 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
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.
> > - 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.
> > - 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?
Bash says:
-> printf "%d\n" foo
-bash: printf: foo: invalid number
0
So it is _not_ 1 ...
> > - 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...
> 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?
What makes you think so?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ernest asks Frank how long he has been working for the company.
"Ever since they threatened to fire me."
More information about the U-Boot
mailing list