Can I move both conditions into 1 condition

Question

I've only been doing scripting a few weeks, and I've managed to write the script at the bottom of this post and get it to work. However, I know that what I need to do really is move the bottom if statement condition into the if statement above. So I need to do a condition like this:

If file exists (and isn't a empty string) AND is either one of these 2: ("switchport mode access" OR "switchport trunk allowed vlan").

I feel that if I did something like the below (not sure the syntax is correct, but doesn't matter because I'm just explaining):

     ###### 1 #####        ################ 2 ####################     ######## 3 ########
if ([ ! -z "${prev}" ] && [ "$line" = "switchport access vlan $i" ] || [[ $line =~ $regex ]]);then

Then I'm worried I don't understand how it groups it. So if we call each condition 1,2,3. So does it mean condition 1&2 OR 3. Or does this man condition 1 & (2-OR-3)? Like, is there a way I could even clear up any ambiguity like you would in maths by putting brackets around the bits you want to group. What's the right way to do it?

tmpfiles="$PWD/configs/*.tmp"
prev=
for basefile in $tmpfiles
do
while read line
do
    ## get old vlans and interfaces
    for i in "${oldvlans[@]}"
    do
        if ([ ! -z "${prev}" ] && [ "$line" = "switchport access vlan $i" ]);then
            line1="${prev}"
            line2="${line}"
            echo "${line1}"
            echo "${line2}"
        fi
    done
    ### check for lines with "trunk allowed vlans" on and do a no trunk allowed vlan on them
    regex="switchport trunk allowed vlan*"
    if [ ! -z "${prev}" ] && [[ $line =~ $regex ]];then
        line1="${prev}"
        line2="${line}"
        echo "${line1}"
        echo "no ${line2}"
    fi
prev="${line}"

done < "$basefile" > "$basefile.done"

EDIT: I did some testing below to try and work out the logic since stephane said () is not for grouping test conditions, and I'm confident I proved him/her wrong):

$ var1=sumit ; [ -z "var1" ] && ([ "$var1" = "sxxt" ] || [ "$var1" = "sumit" ]);  echo $?
1
$ var1=sumit ; [ -n "var1" ] && ([ "$var1" = "sxxt" ] || [ "$var1" = "sumit" ]);  echo $?
0

So I think this is the correct way to do a test where I want:

If [condition1] AND if ([condition 2] OR [condition 3] are true). 

But I'm just hacking away at it, and need to just try and get it clarified.

Answer 1

In bash, the cleanest way to do what you want is to use the [[ ]] construct instead of the more limited [ ] and combine the conditions:

if [ ! -z "${prev}" ] && [[ "$line" = "switchport access vlan $i" || "$line" =~ $regex ]];then

Which works as you expect:

$ var1=sumit; [ -z "var1" ] && [[ "$var1" = "sxxt" || "$var1" = "sumit" ]]; echo $?
1
$ var1=sumit; [ -n "var1" ] && [[ "$var1" = "sxxt" || "$var1" = "sumit" ]]; echo $?
0

Now, it is true that you can abuse the ( ) to run the tests in a subshell and check the result but it is ugly, complicated and unnecessary. If you insist on going down this route, at least avoid the subshell and use { } to group the commands:

$ var1=sumit; [ -z "var1" ] && { [ "$var1" = "sxxt" ] || [ "$var1" = "sumit" ] ;}; echo $?
1
$ var1=sumit; [ -n "var1" ] && { [ "$var1" = "sxxt" ] || [ "$var1" = "sumit" ] ;}; echo $?
0

But really, if you're using bash just go for [[ ]]. And if using a POSIX shell, you can use -o:

$ var1=sumit; [ -z "var1" ] && [ "$var1" = "sxxt" -o  "$var1" = "sumit" ] ; echo $?
1
$ var1=sumit; [ -n "var1" ] && [ "$var1" = "sxxt" -o  "$var1" = "sumit" ] ; echo $?
0

Answer 2

Regarding this part:

     ###### 1 #####        ################ 2 ####################     ######## 3 ########
if ([ ! -z "${prev}" ] && [ "$line" = "switchport access vlan $i" ] || [[ $line =~ $regex ]]);then

Then I'm worried I don't understand how it groups it. So if we call each condition 1,2,3. So does it mean condition 1&2 OR 3. Or does this man condition 1 & (2-OR-3)?

The shell doesn't have precedence for && and || in command lists (like the above), but resolves them left to right. So if you have A && B || C, it gets effectively grouped as (A && B) || C. Similarly, A || B && C is (A || B) && C.

Which is not the same as in most other programming languages, where && has precedence over ||. And to make it worse, inside [[ .. ]] conditionals and arithmetic expressions (e.g. $(( .. ))), that precedence is obeyed in Bash too.

So, these two are different:

if [[ a = a ]] || [[ a = a ]] && [[ a = b ]]; then
    echo one
fi
if [[ a = a    ||    a = a    &&    a = b ]]; then
    echo two
fi

(a = a and a = b are silly, of course, but will do for the example.)

It might be best to avoid using command lists for conditionals, and instead do what others have suggested and use [[ ... ]].

That is, as long as you're running Bash or another shell that has it anyway, since [[ ... ]] isn't a standard feature. In a standard POSIX shell, you're limited to command lists.

---

As for your code, I'm not exactly sure if you'd achieve much by combining those three conditions to one conditional, even if grouped properly:

if [ ! -z "${prev}" ] && ( [ "$line" = "switchport access vlan $i" ] || [[ $line =~ $regex ]] ); then

(regardless of if you use a subshell (foo) or a compound group { foo;} for the grouping)

Mostly because the way you have it, you'd have to do both of the two latter tests within the ${oldvlans[@]} loop, but only one of them actually depends on the loop variable. Also the [ ! -z "$prev" ] condition seems like a precondition for the while read loop doing anything, so why not have it separately.

I'd rather split the three rather than combine them:

while read line
do
    if [ -z "$prev" ]; then
        continue
    fi
    ## we know "$prev" is non-empty now
## get old vlans and interfaces
for i in "${oldvlans[@]}"
do
    if [ "$line" = "switchport access vlan $i" ]; then
        ...
    fi
done
### check for  "trunk allowed vlans" etc.
regex="switchport trunk allowed vlan"
if [[ $line =~ $regex ]]; then
    ...
fi

prev="${line}"

done < ...

(Or perhaps first check if the line matches switchport access vlan or switchport trunk allowed vlan and then decide what to do.)

Note that in regular expressions, n* means "zero or more letters n", not "a single n followed by anything", like it does in shell patterns. But in the [[ str =~ regex ]] test, the regex isn't anchored to the start/end of the string anyway (e.g. [[ foobar =~ ob ]] is true), so you don't need that trailing "match anything" anyway.

Some other programming languages might also provide better tools for string processing than the shells do.