On 11/29/25 7:55 PM, Sam James wrote:
>> - for i in ${POLICY_TYPES}; do
>> - if [[ "${i}" == "strict" ]] && [[ "${MODS}" = "unconfined" ]];
>> then
>> + _selinux_postinst() {
>> + if [[ "${1}" == "strict" ]] && [[ "${MODS}" =
>
> Also, consistently use == or = please. I always use == in bash tests
> because When In Bash (as we're already making full use of bashisms).... and I explicitly ban them anywhere I can. :) They are frivolous and pointless (implemented as an alternative name for the same thing). And it's also the number one cause of bashisms in shell scripts with a #!/bin/sh shebang (like ./configure scripts) because if you give people a mindworm they will use it. It doesn't justify its existence by providing useful functionality (the bashism "[[" does, contrarily, justify *its* existence by providing useful functionality). When used, as is quite common to see [ x == x ] -- yes, bash accepts this too -- it silently works when /bin/sh -> bash, and fails when /bin/sh -> $ANYTHING_ELSE. The failure message is inscrutable. $ [ x == x ] dash: 1: [: x: unexpected operator $ [[ x == x ]] dash: 2: [[: not found As bashisms go it is, in my experience, peculiarly un-debuggable. It's already hard enough to teach people how shells work, we don't need this additional poison. If I could, I would deprecate == and make bash emit an unconditional "SyntaxWarning" any time one is evaluated. "When In Bash (as we're already making full use of bashisms)" ... but most bashisms actually have a purpose, actually do something, and actually make your code better. Therefore, practicality says use good tech to do good things. It is deeply impractical to use bad tech to do... nothing. People blindly following blind prescriptivist rules (this IS a reference to tonight's IRC discussion, in case you were wondering) is the reason entire generations of software developers learn via bad example to use "[ x == x]" in POSIX sh. -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
