I am really confused in understanding this. I presume, I can write a return code comparison as give below. Which is better? Why should it be?
RC=$?
if [[ $RC == '0' ]]; then
if [ $RC -eq '0' ]; then
if [ $RC == '0' ]; then
if [ "$RC" == "0" ]; then
if [ "$RC" -eq "0" ]; then
if [[ "$RC" == "0" ]]; then
if (( "$RC" == "0" )); then
if ( "$RC" == "0" ); then
if (( $RC == 0 )); then
if ( $RC == 0 ); then
And some more...
What if RC="A" -- String?
None of the above. In the vast majority of cases, you want to examine the exit code directly from within if. Any code which looks like
command
RC=$?
if [ $RC == 0 ]; then
is much more elegantly, robustly, and idiomatically written
if command; then
unless you specifically need to examine the precise nonzero value of the result code.
To separately address your question about which comparison operator to use, the only fully portable variant is [ with =. The syntax of this legacy Bourne shell operator does not portably support == for equality, so that's wrong (though some shells allow it as a syntactic safety net). The -eq operator compares for numeric equality, while = performs string comparison.
In modern shells, [[ and (( are both viable, depending on whether you care more about string comparisons (which is where [[ makes sense) or arithmetic (which is the domain of (( -- especially useful if the comparison involves some actual calculations on the numbers; but it is definitely the more fringe alternative, as it is not useful at all for string comparisons). [[ also supports pattern matching, so you are not confined to static string comparisons; unlike [, it requires a double equals sign for the string equality comparison. It works around a number of thorny issues with [, included but not limited to correct behavior with unquoted variables and arguments which begin with a dash.
The alternative with a single parenthesis does not do at all what you want. It attempts to run $RC as a command in a subshell.
If you are in Bash it does not segregate its variables by type, but ... a return code is a numeric value, so i will bet in:
rc=$?
if (( ! rc )); then
# rc == 0
Do something
fi
Reason: maintain coherence in relation with the expected type.
Check: http://tldp.org/LDP/abs/html/untyped.html
Related
This question already has answers here:
How to compare strings in Bash
(12 answers)
Closed 4 years ago.
I'm trying to get an if statement to work in Bash (using Ubuntu):
#!/bin/bash
s1="hi"
s2="hi"
if ["$s1" == "$s2"]
then
echo match
fi
I've tried various forms of the if statement, using [["$s1" == "$s2"]], with and without quotes, using =, == and -eq, but I still get the following error:
[hi: command not found
I've looked at various sites and tutorials and copied those, but it doesn't work - what am I doing wrong?
Eventually, I want to say if $s1 contains $s2, so how can I do that?
I did just work out the spaces bit... :/ How do I say contains?
I tried
if [[ "$s1" == "*$s2*" ]]
but it didn't work.
For string equality comparison, use:
if [[ "$s1" == "$s2" ]]
For string does NOT equal comparison, use:
if [[ "$s1" != "$s2" ]]
For the a contains b, use:
if [[ $s1 == *"$s2"* ]]
(and make sure to add spaces between the symbols):
Bad:
if [["$s1" == "$s2"]]
Good:
if [[ "$s1" == "$s2" ]]
You should be careful to leave a space between the sign of '[' and double quotes where the variable contains this:
if [ "$s1" == "$s2" ]; then
# ^ ^ ^ ^
echo match
fi
The ^s show the blank spaces you need to leave.
You need spaces:
if [ "$s1" == "$s2" ]
I suggest this one:
if [ "$a" = "$b" ]
Notice the white space between the openning/closing brackets and the variables and also the white spaces wrapping the '=' sign.
Also, be careful of your script header. It's not the same thing whether you use
#!/bin/bash
or
#!/bin/sh
Here's the source.
Bash 4+ examples. Note: not using quotes will cause issues when words contain spaces, etc. Always quote in Bash IMO.
Here are some examples Bash 4+:
Example 1, check for 'yes' in string (case insensitive):
if [[ "${str,,}" == *"yes"* ]] ;then
Example 2, check for 'yes' in string (case insensitive):
if [[ "$(echo "$str" | tr '[:upper:]' '[:lower:]')" == *"yes"* ]] ;then
Example 3, check for 'yes' in string (case sensitive):
if [[ "${str}" == *"yes"* ]] ;then
Example 4, check for 'yes' in string (case sensitive):
if [[ "${str}" =~ "yes" ]] ;then
Example 5, exact match (case sensitive):
if [[ "${str}" == "yes" ]] ;then
Example 6, exact match (case insensitive):
if [[ "${str,,}" == "yes" ]] ;then
Example 7, exact match:
if [ "$a" = "$b" ] ;then
This question has already great answers, but here it appears that there is a slight confusion between using single equal (=) and double equals (==) in
if [ "$s1" == "$s2" ]
The main difference lies in which scripting language you are using. If you are using Bash then include #!/bin/bash in the starting of the script and save your script as filename.bash. To execute, use bash filename.bash - then you have to use ==.
If you are using sh then use #!/bin/sh and save your script as filename.sh. To execute use sh filename.sh - then you have to use single =. Avoid intermixing them.
I would suggest:
#!/bin/bash
s1="hi"
s2="hi"
if [ $s1 = $s2 ]
then
echo match
fi
Without the double quotes and with only one equals.
$ if [ "$s1" == "$s2" ]; then echo match; fi
match
$ test "s1" = "s2" ;echo match
match
$
I don't have access to a Linux box right now, but [ is actually a program (and a Bash builtin), so I think you have to put a space between [ and the first parameter.
Also note that the string equality operator seems to be a single =.
This is more a clarification than an answer! Yes, the clue is in the error message:
[hi: command not found
which shows you that your "hi" has been concatenated to the "[".
Unlike in more traditional programming languages, in Bash, "[" is a command just like the more obvious "ls", etc. - it's not treated specially just because it's a symbol, hence the "[" and the (substituted) "$s1" which are immediately next to each other in your question, are joined (as is correct for Bash), and it then tries to find a command in that position: [hi - which is unknown to Bash.
In C and some other languages, the "[" would be seen as a different "character class" and would be disjoint from the following "hi".
Hence you require a space after the opening "[".
Use:
#!/bin/bash
s1="hi"
s2="hi"
if [ "x$s1" == "x$s2" ]
then
echo match
fi
Adding an additional string inside makes it more safe.
You could also use another notation for single-line commands:
[ "x$s1" == "x$s2" ] && echo match
For a version with pure Bash and without test, but really ugly, try:
if ( exit "${s1/*$s2*/0}" )2>/dev/null
then
echo match
fi
Explanation: In ( )an extra subshell is opened. It exits with 0 if there was a match, and it tries to exit with $s1 if there was no match which raises an error (ugly). This error is directed to /dev/null.
I've been Bash scripting for a while and I'm wondering if there's any difference between these two forms of negation with the test command:
if [ ! condition ]; then
fi
if ! [ condition ]; then
fi
The first tells the shell to pass the arguments ! condition to test, letting the program take care of the negation itself. On the other hand, the second passes condition to test and lets the shell itself negate the error code.
Are there any pitfalls I should be aware of when choosing between these two forms? What values of $condition could make the results differ between them?
(I seem to remember reading an article a while ago discussing this, but I don't remember how to find it/exactly what was discussed.)
To build on chepner's insightful comment on the question:
In [ ! condition ], the ! is just an argument to the [ builtin (an effective alias of the test builtin); it so happens that [ / test interprets argument ! as negation.
In ! [ condition ], the ! is a shell keyword that negates whatever command it is followed by (which happens to be [ in this case).
One thing that the ! [ condition ] syntax implicitly gives you is that negation applies to whatever [ condition ] evaluates to as a whole, so if that is the intent, you needn't worry about operator precedence.
Performance-wise, which syntax you choose probably doesn't make much of a difference; quick tests suggest:
If condition is literally the same in both cases, passing the ! as an argument to [ is negligibly faster.
If ! is used as a keyword, and you are therefore able to simplify the condition by not worrying about precedence, it may be slightly faster (e.g, ! [ 0 -o 1 ] vs. [ ! \( 0 -o 1 \) ]; note that the POSIX spec. discourages use of -a and -o due to ambiguity).
That said, if we're talking about Bash, then you should consider using [[ instead of [, because [[ is a shell keyword that parses the enclosed expression in a special context that:
offers more features
allows you to safely combine expressions with && and ||
comes with fewer surprises
is also slightly faster (though that will rarely matter in pratice)
See this answer of mine.
! negates the exit code of following command :
$ ! test 1 = 1 || echo $? # negate command with true expression
1
As said in man page, test (and similar [ builtin) exit with the status determined by following expression :
$ test ! 1 = 1 || echo $? # return false expression
1
$ [ ! 1 = 1 ] || echo $?
1
For a given expression :
on one side you negate the test command that exit with true expression status.
on the other side, you negate an expression and the test command (or [) exit with its false status
Both will have the same effect.
So I would say that these syntax are equivalent. With the advantage for external ! to allow negate compound tests :
$ ! [ 1 = 1 -a 2 = 2 ] || echo $?
1
There is a difference if test/[ faces an error. Consider:
x=abc
if [ ! "$x" -gt 0 ]; then echo "first true"; fi
if ! [ "$x" -gt 0 ]; then echo "second true"; fi
The output is:
bash: [: abc: integer expression expected
second true
Unlike [[ .. ]], test/[ works like regular utility and signals errors by returning 2. That's a falsy value, and with ! outside the brackets, the shell inverts it just the same as a regular negative result from the test would be inverted.
With [[ .. ]] the behaviour is different, in that a syntax error in the condition is a syntax error for the shell, and the shell itself exits with an error:
if [[ a b ]]; then echo true; else echo false; fi
prints only
bash: conditional binary operator expected
bash: syntax error near `b'
with no output from the echos.
On the other hand, arithmetic tests work differently within [[ .. ]] so [[ "$x" -gt 0 ]] would never give an error.
I'd like to use the result of a comparison in a subsequent comparison. I'm trying to do something like:
# $1 - expected result
# $2 - actual result
function print_result() {
if [[ [[ $1 -eq 0 ]] -eq [[ $2 -eq 0 ]] ]]; then # invalid
echo "Pass"
else
echo "Fail"
fi
}
I can get the desired behaviour with the more verbose form:
function print_result() {
if [[ (($1 -eq 0) && ($2 -eq 0)) || (($1 -ne 0) && ($2 -ne 0)) ]]; then
echo "Pass"
else
echo "Fail"
fi
}
but it seems like there should be a simpler way?
You need something which produces the result of the comparison operator as text rather than as a status return. That would be arithmetic expansion: $((expression)).
Note also that bash includes a numeric conditional compound statement -- (( expr )) -- which is often easier to use for numerical comparisons than the non-numerical [[ ... ]] conditional compound statement.
Putting that together, what you are looking for is:
if (( $(($1==0)) == $(($2==0)) )); then
Or just:
if (( ($1==0) == ($2==0) )); then
If you only want to know if $1 and $2 are both zero or both non-zero, then you can use the fact that boolean not (!) always evaluates to either 0 or 1. Consequently, the following even simpler expression is equivalent (but see warning below):
if ((!$1 == !$2)); then
Important: If you use that in a script, it will work fine, but at the command prompt you need to put a space after the ! to avoid it being interpreted as a history expansion character (unless you've turned history expansion off: if you don't actually use history expansion, turning it off is not a bad idea.)
A possibly slightly more readable (but not particularly simpler) way would be to store the result of each comparison in a variable and then compare the variables:
function print_result() {
[[ $1 -eq 0 ]]; arg_one_is_zero=$?
[[ $2 -eq 0 ]]; arg_two_is_zero=$?
if [[ $arg_one_is_zero -eq $arg_two_is_zero ]]; then
echo "Pass"
else
echo "Fail"
fi
}
There might be a better way to store the logical result (exit code) of a comparison in a variable but I couldn't find one after a quick look.
This question differs in that the classic "use a function" answer WILL NOT work. Adding a note to an existing Alias question is equivalent to sending a suggestion e-mail to Yahoo.
I am trying to write macros to get around BASH's horrendous IF syntax. You know, the [, [[, ((...BASH: the PHP of flow control...just add another bracket. I'm still waiting for the "(((((((" form. Not quite sure why BASH didn't repurpose "(", as "(" has no real semantics at the if statement.
The idea is to have named aliases for [, [[ and (( , as each one of these durned test-ish functions has a frustratingly different syntax. I honestly can never remember which is which (how COULD you? It's completely ad hoc!), and good luck trying to google "[[".
I would then use the names as a mnemonic, and the alias to get rid of the completely awful differences in spacing requirements. Examples: "whatdoyoucallthisIf" for "((", "shif" (for shell if), "mysterydoublesquarebacketif" for that awful [[ thing which seems to mostly do the same thing as [, only it doesn't.
Thus, I MUST have something of the form:
alias IFREPLACEMENT="if [ \$# ]; then"
But obviously not \$#, which would just cement in the current argument list to the shell running the alias.
Functions will not work in this case, as the function:
function IFREPLACEMENT {
if [ $# ]; then
}
is illegal.
In CSH, you could say
alias abc blah blah !*
!1, etc. Is there ANYTHING in BASH that is similar (no, !* doesn't work in BASH)?
Or am [ "I just out of luck" ]; ?
As an aside, here are some of the frustrating differences involving test-ish functions in BASH that I am trying to avoid by using well-defined aliases that people would have to use instead of picking the wrong "[[", "[" or "((":
"((" is really creepy...if a variable contains the name of another variable, it's derferenced for as many levels as necessary)
"((" doesn't require a spaces like '[' and '[['
"((" doesn't require "$" for variables to be dereferenced
['s "-gt" is numeric or die. [[ seems to have arbitrary restrictions.
'[' and '[[' use ">" (etc) as LEXICAL comparison operators, but they have frustratingly different rules that make it LOOK like they're doing numeric comparisons when they really aren't.
for a variable: a="" (empty value), [ $a == 123 ] is a syntax error, but (( a == 123 )) isn't.
Sure, functions will work, but not like a macro:
function IFREPLACEMENT {
[[ "$#" ]]
}
IFREPLACEMENT "$x" = "$y" && {
echo "the same
}
FWIW, here's a brutal way to pass arguments to an alias.
$ alias enumerate='bash -c '\''for ((i=0; i<=$#; i++)); do arg=${!i}; echo $i $arg; done'\'
$ enumerate foo bar baz
0 foo
1 bar
2 baz
Clearly, because a new bash shell is spawned, whatever you do won't have any effect on the current shell.
Update: Based on feedback from #konsolebox, the recommendation is now to always use [[...]] for both simplicity and performance (the original answer recommended ((...)) for numerical/Boolean tests).
#Oliver Charlesworth, in a comment on the question, makes the case for not trying to hide the underlying bash syntax - and I agree.
You can simplify things with the following rules:
Always use [[ ... ]] for tests.
Only use [ ... ] if POSIX compatibility is a must. If available, [[ ... ]] is always the better choice (fewer surprises, more features, and almost twice as fast[1]).
Use double-quoted, $-prefixed variable references - for robustness and simplicity (you do pay a slight performance penalty for double-quoting, though1) - e.g., "$var"; see the exceptions re the RHS of == and =~ below.
Whitespace rules:
ALWAYS put a space after the initial delimiter and before the closing delimiter of conditionals (whether [[ / (( or ]] / )))
NEVER put spaces around = in variable assignments.
These rules are more restrictive than they need to be - in the interest of simplification.
Tips and pitfalls:
Note that for numeric comparison with [[ ... ]], you must use -eq, -gt, -ge, -lt, -le, because ==, <, <=, >, >= are for lexical comparison.
[[ 110 -gt 2 ]] && echo YES
If you want to use == with pattern matching (globbing), either specify the entire RHS as an unquoted string, or, at least leave the special globbing characters unquoted.
[[ 'abc' == 'a'* ]] && echo YES
Similarly, performing regex matching with =~ requires that either the entire RHS be unquoted, or at least leave the special regex chars. unquoted - if you use a variable to store the regex - as you may have to in order to avoid bugs with respect to \-prefixed constructs on Linux - reference that variable unquoted.
[[ 'abc' =~ ^'a'.+$ ]] && echo YES
re='^a.+$'; [[ 'abc' =~ $re ]] && echo YES # *unquoted* use of var. $re
An alternative to [[ ... ]], for purely numerical/Boolean tests, is to use arithmetic evaluation, ((...)), whose performance is comparable to [[ (about 15-20% slower1); arithmetic evaluation (see section ARITHMETIC EVALUATION in man bash):
Allows C-style arithmetic (integer) operations such as +, -, *, /, **, %, ...
Supports assignments, including increment and decrement operations (++ / --).
No $ prefix required for variable references.
Caveat: You still need the $ in 2 scenarios:
If you want to specify a number base or perform up-front parameter expansion, such as removing a prefix:
var=010; (( 10#$var > 9 )) && echo YES # mandate number base 10
var=v10; (( ${var#v} > 9 )) && echo YES # strip initial 'v'
If you want to prevent recursive variable expansion.
((...), curiously, expands a variable name without $ recursively, until its value is not the name of an existing variable anymore:
var1=10; var2=var1; (( var2 > 9 )) && echo YES
var2 expands to 10(!)
Has laxer whitespace rules.
Example: v1=0; ((v2 = 1 + ++v1)) && echo YES # -> $v1 == 1, $v2 == 2
Caveat: Since arithmetic evaluation behaves so differently from the rest of bash, you'll have to weigh its added features against having to remember an extra set of rules. You also pay a slight performance penalty1.
You can even cram arithmetic expressions, including assignments, into [[ conditionals that are based on numeric operators, though that may get even more confusing; e.g.:
v1=1 v2=3; [[ v1+=1 -eq --v2 ]] && echo TRUE # -> both $v1 and $v2 == 2
Note: In this context, by 'quoting' I mean single- or double-quoting an entire string, as opposed to \-escaping individual characters in a string not enclosed in either single- or double quotes.
1:
The following code - adapted from code by #konsolebox - was used for performance measurements:
Note:
The results can vary by platform - numbers are based on OS X 10.9.3 and Ubuntu 12.04.
[[ being nearly twice as fast as [ (factor around 1.9) is based on:
using unquoted, $-prefixed variable references in [[ (using double-quoted variable references slows things down somewhat)
(( is slower than [[ with unquoted, $-prefixed variable on both platforms: about 15-20% on OSX, around 30% on Ubuntu. On OSX, using double-quoted, $-prefixed variable references is actually slower, as is not using the $ prefix at all (works with numeric operators). By contrast, on Ubuntu, (( is slower than all ]] variants.
#!/usr/bin/env bash
headers=( 'test' '[' '[[/unquoted' '[[/quoted' '[[/arithmetic' '((' )
iterator=$(seq 100000)
{
time for i in $iterator; do test "$RANDOM" -eq "$RANDOM"; done
time for i in $iterator; do [ "$RANDOM" -eq "$RANDOM" ]; done
time for i in $iterator; do [[ $RANDOM -eq $RANDOM ]]; done
time for i in $iterator; do [[ "$RANDOM" -eq "$RANDOM" ]]; done
time for i in $iterator; do [[ RANDOM -eq RANDOM ]]; done
time for i in $iterator; do (( RANDOM == RANDOM )); done
} 2>&1 | fgrep 'real' | { i=0; while read -r line; do echo "${headers[i++]}: $line"; done; } | sort -bn -k3.3 | awk 'NR==1 { baseTime=substr($3,3) } { time=substr($3,3); printf "%s %s%%\n", $0, (time/baseTime)*100 }' | column -t
Outputs times from fastest to slowest, with slower times also expressed as a percentage of the fastest time.
I tried to play around with bash, and even tried documentation and few threads though I cannot seem to get it right.
S=(true false)
if (( ${S[0]} || ${S[1]} ))
then
echo "true"
else
echo "false"
fi
how can the boolean expression be evaluated under bash? (any chance to fix the snippet above?)
is there any possibility to evaluate it without if, i.e. assign it to a variable directly (no if manipulation)?
Instead of S=(true false), you need to create your array like this:
S=(1 0)
Then this if block:
if (( ${S[0]} || ${S[1]} ))
then
echo "true"
else
echo "false"
fi
will output:
true
Please note that true/false are treated as literal strings "true" and "false" in BASH.
There isn't really such a thing as boolean in bash, only integral arithmetic expressions e.g. (( n )), which would return an exit code of 0 (no error or no failure code) if its value is greater than 1, or a nonzero code (has error code) if it evaluates to 0. if statements execute a then block if the command it calls returns 0 exit code, or on the else block otherwise. You can imitate boolean systems in bash like this though:
#!/bin/bash
true=1
false=0
A=true
B=false
# Compare by arithmetic:
if (( A || B )); then
echo "Arithmetic condition was true."
else
echo "Arithmetic condition was false."
fi
if (( (I > 1) == true )); then ## Same as (( I > 1 )) actually.
echo "Arithmetic condition was true."
else
echo "Arithmetic condition was false."
fi
# Compare by string
if [[ $A == true || $B == true ]]; then
echo "Conditional expression was true."
else
echo "Conditional expression was false."
fi
# Compare by builtin command
if "$A" || "$B"; then
echo "True concept builtin command was called."
else
echo "False concept builtin command was called."
fi
And I prefer the string comparison since it's a less hacky approach despite probably being a bit slower. But I could use the other methods too if I want too.
(( )), [[ ]], true, and false all are just builtin commands or expressions that return an exit code. It's better that you just think of the like that than thinking that they are really part of the shell's main syntax.