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