[PATCH v2 2/3] allow positional arguments with "run" command

[Rasmus Villemoes <rasmus.villemoes@prevas.dk>]

On 19/10/2020 09.31, Wolfgang Denk wrote:
> Dear Rasmus,
> 
> In message <2284dd1d-f20c-6246-805e-55454a581960@prevas.dk> you wrote:
>>
>>> 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.
> 
> Yes, current versions of busybox hush do implement shell functions;
> tested under Fedora 32:

Not what I meant, of course busybox hush does that. What I meant is that
it is not at all obvious how that support would actually benefit U-Boot.
The problem is how one would go about getting the functions defined. Putting

define_func='func() { do_stuff $1 $2; do_more_stuff $3; }'

in the environment and then having to say

run define_func; func foo ...

does not really look like an improvement to me. In contrast, the current
way of defining "one-liner" functions and running with, well, run, is
quite ergonomic - but I do miss the ability to provide parameters other
than via global settings. With these patches, the above would just be

func='do_stuff $1 $2; do_more_stuff $3;'

run func -- foo ...

I guess one could have something like CONFIG_DOT_PROFILE and have that
point at a script that gets built into the U-Boot binary and sourced at
shell startup; then one could put one's functions in there, or have the
flexibility of having that file load some stdlib.sh from somewhere.

> 
> My big concern here is that adding bells and whistles to our ancient
> version of hush will just make it all the harder to upgrade to a
> recent version.  Already now we have the situation that we must be
> afraid to break existing code which works around some of the
> problems.  Adding more "special code" will not make this better.
> 
> And even if we can upgrade to a new version independently, we still
> might have to keep this workaround code for compatibility, as people
> started using it, and it is not compatible with any existing shell.
> 
> So the _much_ better approach would indeed be to upgrade to a recent
> version of hush.

I agree in principle - there are other shell features I'm also missing
(though see above, I don't immediately see how an upgrade would make
functions available in a useful way).

Someone speaking up and saying "I'm going to look at an overhaul of hush
within the next year or so" would clearly be a strong argument against
inclusion of these patches. Lacking such a pony promise, this really
boils down to an idealist/pragmatist issue, and we can keep going around
this in circles forever, so I think someone (Tom?) should make a decision.

Rasmus