Fix L0_backend_python iGPU PyTorch installation

[kthui]

Before the fix, the test was comparing

+ [[ 1 == \0 ]]

for

[[ "$TEST_JETSON" == "0" ]]

After the fix, the comparison is restored to

+ '[' 1 == 0 ']'

Also fix a comparison logic error in using || and &&, before

if [[ "$TEST_JETSON" == "0" ]] || [[ ${TEST_WINDOWS} == 0 ]]; then
    # Run Linux setup
else
    # Run iGPU or Windows setup
fi

after

if [ "$TEST_JETSON" == "0" ] && [[ ${TEST_WINDOWS} == 0 ]]; then
...

[kthui]

@fpetrini15 I couldn't get the Windows build to work. Do you see any concern on Windows test using one square bracket comparison instead of two? i.e. [ "$TEST_JETSON" == "0" ] vs [[ "$TEST_JETSON" == "0" ]]

(The Jetson comparison is comparing a string, while the Windows comparison is comparing an integer)

[fpetrini15]

@kthui good catch on the incorrect logical operator!

With respect to the brackets, I believe the guidance is to use the double bracket notation whenever possible. For example, if we have the following script where $TEST_JETSON was left unquoted:

#!/bin/bash
TEST_JETSON=
if [[ $TEST_JETSON == "0" ]]; then
        echo "FLAG equals 0"
else
        echo "FLAG does not equal 0"
fi

Will correctly evaluate to the else condition with no error.

With single brackets:

#!/bin/bash
TEST_JETSON=
if [ $TEST_JETSON == "0" ]; then
        echo "FLAG equals 0"
else
        echo "FLAG does not equal 0"
fi

We will get the error: test.sh: line 3: [: ==: unary operator expected

I know this is assuming layers of mistakes made by a developer, but I believe the double-bracket is still best-practice.

Additionally, though bash -x seems to interpret "0" / "1" as \0 and \1 when it prints to console, the comparison appears to be sound and will correctly evaluate.

All that said, as it relates to your original question, I see no issue, though it would probably be more correct to use the -eq operator if we expect an integer. I tested the cases locally with no issue, but I will follow-up if I see a failure.

[kthui]

@fpetrini15 thanks for checking it on Windows! I have no issue moving everything to double bracket, as long as it doesn't backfire on us.

On your single bracket case, if you double quote the "$TEST_JETSON" variable, it works on my local machine:

#!/bin/bash
TEST_JETSON=
if [ "$TEST_JETSON" == "0" ]; then
        echo "FLAG equals 0"
else
        echo "FLAG does not equal 0"
fi

The double quote variant is what is used on the test script and it is already passing on the CI. I don't thinks this will become an issue on the test on x86 in the future.

Do you think it is ok to keep the single bracket for the "$TEST_JETSON" variable for now? It's because we want to pick this fix into 24.05 release and this variant is already passing on the CI. If we switch to the double bracket variant, we will have to run the CI again and likely have another half day delay on this.

[fpetrini15]

@kthui you are correct. If you add quotes to the variable there is no issue. In general, I understand there is no issue now, but I believe it is an additional safeguard for the future. Just something I wanted to start a discussion about.

Either way, not important enough to hold up this PR/release. You can merge when ready! 🚀

[tanmayv25]

Thanks @kthui for the quick fix!