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

[Sean Anderson]

On 7/2/21 7:30 AM, Wolfgang Denk wrote:
> 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

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