It's a little contrived in this case, but another common example is a related suggestion for `read -r`:
get_nix_version_parts(){
local major minor patch
# shellcheck disable=SC2034,SC2162
IFS="." read major minor patch < <(get_nix_version)
local -p
}
$ get_nix_version_parts
major=2
minor=3
patch=4
Using -r there works fine for me, though your SC2034 complaint is valid, in that it essentially prevents from you from using a very specific built in formatter provided by "local -p".
This feels like a rare case, and I'd have no problem doing the "disable=SC2034" there, but I'd add a note explaining why.
Even then, one could make an argument (I think I would, actually) that an explicit printf is clearer and more robust. For example, it gives you more control over the formatting, and it doesn't introduce implicit coupling between the output of "local -p" and our function, which in theory could change in the future or be different on different bash versions, etc. I suspect this probability is very low in the particular case of local -p, but still it's not a great practice. Not something I want to give the stamp of approval of inside my code base.
get_nix_version_parts(){
local major minor patch
IFS="." read -r major minor patch < <(nixv)
printf '%s=%s\n' major "$major" minor "$minor" patch "$patch"
}
Good catch on -r not mattering, here. I think `read` is one I've had trouble with and assumed that was it since I bothered disabling it. But after grepping around a bit more, the only one I see that shellcheck would object to that actually differs isn't common enough that I'd gripe about it.
I don't actually have a gripe with 2034, here. It's a good example of a statement that the user obviously has to triage.
Likewise, I'm just using `local -p` as a cheap way to show that the variables populate, it wasn't part of the original code I adapted. Yes--the case for coupling to the output of local -p is when the output is going to be used to set variables again later.
