LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   bash script string compare (https://www.linuxquestions.org/questions/linux-newbie-8/bash-script-string-compare-4175599207/)

Habitual 02-07-2017 05:08 PM

Quote:

Originally Posted by rknichols (Post 5666802)
In both the "[ ... ]" and "[[ ... ]]" constructs in bash, the ">" and "<" operators perform a string comparison. If you want numeric comparison you have to use "-gt" and "-lt".

Every day a refresher course! Want being the keyword, I guess.
Thank you.

ondoho 02-08-2017 12:50 AM

Quote:

Originally Posted by secomax (Post 5666712)
Code:

\>

i'm really bothered by this.
why escape the '>' in the first place?
why doesn't it throw an error?

MadeInGermany 02-08-2017 01:05 AM

Code:

[ "$val1" \> "$val2" ]
is a test command, and can be written as
Code:

test "$val1" \> "$val2"
Command arguments are subject to word splitting and expansion before execution (in the test command).
An unquoted > would be a redirection to a file, therefor the escape. You can also escape it with
Code:

test "$val1" ">" "$val2"
What counts is that the test sees 3 strings, where the 2nd it wants an operator.
This is different in the [[ ]] compound where the shell parser directly handles the operation without prior word splitting or expansion.
Code:

[[ $val1 > $val2 ]]

secomax 02-08-2017 01:36 AM

Does that means I have to quote every instance of the string that contains spaces ?

pan64 02-08-2017 01:51 AM

Quote:

Originally Posted by ondoho (Post 5666956)
i'm really bothered by this.
why escape the '>' in the first place?
why doesn't it throw an error?

because syntactically correct, although it is just annoying and pointless.

Quote:

Does that means I have to quote every instance of the string that contains spaces ?
It is a really good idea, but there can be cases when you do not want to quote. So in general yes, but in special cases probably not.

secomax 02-08-2017 03:13 AM

If I remove the escape from it will give error
because the bash think it is an output redirection

Quote:

It is a really good idea, but there can be cases when you do not want to quote. So in general yes, but in special cases probably not.
Thanks for your help
I'm in love with bash scripts and bash tricks

pan64 02-08-2017 03:23 AM

Quote:

Originally Posted by secomax (Post 5667005)
If I remove the escape from it will give error

Oh, yes, that is only working with [[ ]] (one more reason to use [[ ]] instead of [ ])

secomax 02-08-2017 04:53 AM

Really thanks a lot

r3sistance 02-08-2017 07:05 AM

another advantage to [[ ]] compared to [ ] is what if val1 or val2 were empty or null?

Code:

#cat strtest.sh
val1=
val2="somestring"

if [[ $val1 > $val2 ]]; then echo true; fi
#./strtest.sh
#

compared too

Code:

#cat strtest.sh
val1=
val2="somestring"

if [ $val1 \> $val2 ]; then echo true; fi
#./strtest.sh
./strtest.sh: line 4: [: >: unary operator expected

That is another behavioral difference to be aware of. This behavior will also be experienced if 'val1=""' too

MadeInGermany 02-08-2017 12:15 PM

Empty variables are another reason for the rule:
always quote variables in command arguments, including the [ ] test command.
Literal strings that contain a space must always be in quotes.
Examples
Code:

var=* # assignment, does not need to be quoted.
var="* *" # literal string with whitespace, needs quotes

var="two words"
if [[ $var > "two words" ]]; then
  echo "$var comes after 'two words' in the alphabet"
fi

var="one two words"
case $var in
( *"two words"* )
  echo "'two words' found in '$var'."
;;
esac

if [[ $var == *"two words"* ]]; then
  echo "'two words' found in '$var'."
fi

One additional note: $var in 'ticks' is normally not expanded by the shell, but here the 'ticks' are within "quotes" so loose their special meaning.

secomax 02-10-2017 06:52 AM

thanks for you all
it helped me

Habitual 02-10-2017 07:57 AM

You are welcome.

Go TeamLQ!


All times are GMT -5. The time now is 07:42 PM.