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:
-> rpm -q busybox busybox-1.31.1-2.fc32.x86_64 -> cd /tmp -> ln -s /sbin/busybox hush -> ./hush -> foo() {
echo argc=$# arg1=$1 arg2=$2 arg3=$3 }
-> foo argc=0 arg1= arg2= arg3= -> foo aa argc=1 arg1=aa arg2= arg3= -> foo aa bb argc=2 arg1=aa arg2=bb arg3= -> foo aa bb cc argc=3 arg1=aa arg2=bb arg3=cc -> foo aa bb cc dd argc=4 arg1=aa arg2=bb arg3=cc -> exit
No, I cannot see any shell / hush related test code in the busybox repository.
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).
Well, that's note really the same. For shell functions, ther eis now a (hopefully) clean implementation in recent versions of hush, so upgrading to a recent version would not only solve the problem/task we're discussing here, but also bring a lot of other bug fixes and improvements.
The examples you mentioned above are moe related to U-Boots concept of environment handling, which is idependent of the shell we are using i. e. it's the same with U-Boots own trivial command parser.
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.
Best regards,
Wolfgang Denk