I think this is a problem with the precedence of && vs ||. If INSMOD is not set, it will work as you intend, but once it's set, only the || branch will execute.

You can fix it if you group the assignments together:

[ -z "$INSMOD" ] && (INSMOD=$(which modprobe) || INSMOD="$(which insmod)")

On Sat, Feb 27, 2021 at 01:32:55PM -0800, Kenneth Porter wrote:

In the sqm-scripts package for managing network traffic shaping is this line for finding a program suitable for loading the kernel shaping modules:

[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)

It seems to set INSMOD to /usr/sbin/insmod, even though /usr/sbin/modprobe is available. (Both are symlinks to ../bin/kmod.)

According to this article, the return value of the first assignment should be success and it shouldn't take the fallback statement:

https://unix.stackexchange.com/questions/270828/how-is-the-return-status-of-a-variable-assignment-determined

Also working the issue here:

https://github.com/tohojo/sqm-scripts/issues/133

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On 2/27/21 1:32 PM, Kenneth Porter wrote:

[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)

It seems to set INSMOD to /usr/sbin/insmod, even though /usr/sbin/modprobe is available. (Both are symlinks to ../bin/kmod.)

[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)

This should be re-written as:

[ -z "$INSMOD" ] && { INSMOD=$(which modprobe) || INSMOD=$(which insmod) ; }

As it is currently written, if INSMOD is set previously, it will be replaced with the output of "which insmod".  That is, the final statement will be evaluated if either INSMOD was set previously, or if "which modprobe" exits with a non-zero status.

It's unlikely that this is a PATH issue since both modprobe and insmod are in the same directory.  The most likely explanation is that $INSMOD had a value before that line was evaluated.