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