Re: [RFC PATCH 02/28] cli: Add LIL shell

From: Sean Anderson <seanga2@gmail.com>
To: Wolfgang Denk <wd@denx.de>, Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de, "Marek Behún" <marek.behun@nic.cz>,
	"Simon Glass" <sjg@chromium.org>,
	"Roland Gaudig" <roland.gaudig-oss@weidmueller.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Kostas Michalopoulos" <badsector@runtimeterror.com>
Subject: Re: [RFC PATCH 02/28] cli: Add LIL shell
Date: Wed, 7 Jul 2021 09:46:20 -0400	[thread overview]
Message-ID: <49e131a6-a638-41de-486b-c814233bf924@gmail.com> (raw)
In-Reply-To: <49439.1625645734@gemini.denx.de>

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