On 15/10/2020 17.05, Simon Glass wrote: > Hi Rasmus, > > On Mon, 12 Oct 2020 at 01:06, Rasmus Villemoes > <[email protected]> wrote: >> >> On 12/10/2020 05.34, Simon Glass wrote: >>> On Wed, 7 Oct 2020 at 01:21, Rasmus Villemoes >>> <[email protected]> wrote: >>>> >>>> cmd/Kconfig | 10 ++++++++++ >>>> cmd/nvedit.c | 7 ++++++- >>>> common/cli.c | 44 ++++++++++++++++++++++++++++++++++++++------ >>>> common/cli_hush.c | 32 +++++++++++++++++++++++++++++++- >>>> include/cli_hush.h | 9 +++++++++ >>>> 5 files changed, 94 insertions(+), 8 deletions(-) >>>> >>> >>> Reviewed-by: Simon Glass <[email protected]> >>> >>> I'm not sure where the previous discussion went. But please think >>> about how we can add some tests here. >> >> Isn't that exactly what I do in 3/3? Or are you thinking of something else? >> > > Yes that's good, but is the plan now to take these patches rather than > update to the latest hush? I was wondering is Buzybox has any tests > for hush.
Well, updating the whole hush code is not, as I've said before, something I can or will take on me ATM, and it's not even clear that that would automatically provide real shell functions. Whether "the plan" includes accepting these patches I can't say. I'm just trying to plug a hole and make the U-Boot shell a little more usable. It's somewhat similar to the setexpr command; we don't have $((a+4)) arithmetic, but can achieve the same thing with an extra command. Or askenv, which takes the place of 'read -p'. Or run, for that matter, which combined with setenv can do much of what eval in a POSIX shell could do. And with 3/3, there's a place to put tests of e.g. setexpr (not that adding the boilerplate is hard, but it is a tedious first step; once that is in place, adding extra test cases is somewhat easier and natural). Rasmus
