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