Consider the following, as executed in the loksh shell. # printf '%s\n' '#!/bin/sh' > cmd1 # chmod +x cmd1 # cmd2() { :; } # unset LEAKED # LEAKED=1 ./cmd1; echo "LEAKED = $LEAKED" LEAKED = # LEAKED=1 cmd2; echo "LEAKED = $LEAKED" LEAKED = 1 This shows a variable assignment incorporated by a simple command being allowed to persist beyond the execution environment established for said simple command, provided that it is charged with calling a function. I discovered this with the aid of the unit tests for sys-apps/gentoo-functions. Strictly speaking, such behaviour is permitted. The Shell Command Language specification states: """ If the command name is a function that is not a standard utility implemented as a function, variable assignments shall affect the current execution environment during the execution of the function. It is unspecified: - Whether or not the variable assignments persist after the completion of the function - Whether or not the variables gain the export attribute during the execution of the function - Whether or not export attributes gained as a result of the variable assignments persist after the completion of the function (if variable assignments persist after the completion of the function) """ Unfortunately, loksh elects not to be aligned with the practices of the overwhelming majority of implementations in this regard. I can state with confidence that this makes it very risky to have it as the /bin/sh implementation. That is, it *will* break scripts in the wild. I don't think that this is necessarily a reason to drop loksh as a potential target but I do think that it may be a reason to prevent hapless users from being able to casually select it. As such, I wonder whether it should be package.use.masked.
I would also suggest considering the same question of "ksh", albeit for different technical reasons. However, I'll file a distinct issue for that.
Never mind. I conflated the loksh shell with the purpose of the lksh flag. Closing and please excuse the noise.
