Re: [RFC PATCH 00/28] cli: Add a new shell

Wolfgang Denk
2021-07-02T11:30:24Z

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

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@denx.de
Ernest asks Frank how long he has been working for the company.
"Ever since they threatened to fire me."