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

[Wolfgang Denk <wd@denx.de>]

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."