On 7/7/21 4:15 AM, Wolfgang Denk wrote:
Dear Tom,
In message <20210706154346.GT9516@bill-the-cat> you wrote:
I'm pretty confident that exactly zero people have written complex
U-Boot scripts and then been happy about the experience.
I have seen many U-Boot scripts which were pretty complex, but
working absolutely reliably.
TCL has its fans. csh has it's fans. The question isn't what's the
best desktop shell or general scripting language, but what's the most
useful in our environment an use cases.
Maybe you should try and do a poll of our user base which CLI they
_want_? I doubt there will be any significant percentage voting for
Tcl.
I know of a large number of systems which offer a shell interface on
their command line, and those who don't usually use completely
proprietary code. I know of very few examples where Tcl is being
used.
Off the top of my head, most of the tooling for FPGAs uses TCL for
scripting. OpenOCD uses it too.
I don't know if it's right either. But drawing on my comment just now
and above about complex boot scripts, I also don't know if "it's sh but
quirky and incomplete, WHY DOESN'T THIS WORK RIGHT" is better than "It's
TCL? I don't know that, let me hit stackoverflow and do a little
reading" as would be the common experience. Especially if we document
up-front what the quirks we have are.
Point taken. But if you think this to an end, the result is: lets
write some documentation and explain the limitations of a shell in
U-Boot environment, and document the warts and bugs of this (or an
updated) version of hush. This should make more users happy than
completely new and incompatible stuff.
Frankly, I believe when you run into problems with hush in U-Boot
(even the current version) you should lean back and think about what
you are doing.
U-Boot is a boot loader, and while it is powerful enough to do
complex things, this is not necessarily the most clever approach.
15 years ago, I've written complex update scripts for U-Boot. This
was easy enough to do, and worked perfectly. But there are so many
limitations in a boot loader environment. We don't do this any
more. Instead, we use an OS suitable for such tasks (Linux with
SWUpdate).
And talking about problems and limitations in U-Boot... Is the CLI
really our biggest concern right now? None of our users (customers)
has asked for a better command interpreter - the question we hear
are more like: "When will you support IPv6?", "NFS does not work
with recent Linux distros, will this be fixed?", "Can I download
over WiFi?", "Can I download using HTTP/HTTPS?", "How can I harden
U-Boot for security-critical environments?", etc.
I wanted a better shell, so I worked on it.
--Sean
