On Sun, 17 Mar 2024, Greg Wooledge wrote:
Tim's assumption here is that he can write a function which emits a
stream of whitespace-separated words, and use this safely in an unquoted
command substitution.
count $(args)
I'm guessing "count" is a stand-in for something more complex, but $(args)
is pretty much exactly what he wants to do in his real script.
Yes, thanks, this is exactly it.
Taken me most of the weekend but I've managed to get rid of everything
except a handful of places where shellcheck can't understand/follow.
Some "computed" sourced files, a few places I'm using sed where it says
to try // / stuff - and I might revisit one day, and a couple of other
places that I don't want to change but are correct.
This exercise found two bugs - one had a workaround that I now need to
revisit. The other was because I could no longer use an associative
array to hold a space split string but had to use a computed variable to
hold a list.
There was nothing wrong with the data in the array but the array index
was wrong, which shellcheck couldn't spot either way but v_$a was not a
valid variable name, which it would have been if the array index was
correct.
And then I've spent a lot of time tracking down the new bugs. The
hardest of which was down to changing $a into "$a" resulted in a leading
space in a function parameter.
The problem is that this works *brilliantly* with inputs that are
heavily restricted to a specific set of characters, and fails *utterly*
if the inputs do not conform to that limitation. There is no middle
ground, and there is no way to fix it up. Once your inputs take off
their training wheels, you have to throw this script away and rewrite
it from the ground up.
This is true, but at the point debian has an architecture with a space
in the name is probably the point I rewrite it in python :-)
That's why shellcheck gives warnings about this kind of thing. (Well,
one of many reasons.)
