I'm trying to make a rather simple bash script where if the input is "on 1" it will execute an action and if it is "on 2" it will execute another action. I did a bit of googling about to find out how people were making the and operator work in bash scripts, I found a lot of different ways and none of them seemed to work, until I found to replace my brackets[] with parentheses().


if (($1=="on" && $2=="1")); then
    echo $1 $2
    echo failure

Once I got that far, what happens is that my script is accepting the second argument, but not the first. So if I write "off 1" the script gets executed even if $1 wasn't "on" like the if should be demanding, however if I write "on 2" the code jumps to my else statement.

How do I make it read both arguments properly instead of only the second?

  • (( )) is for numeric operations. Numbers only. You're looking for [[ ]]. – muru Feb 11 '15 at 19:21
  • use for example this: if [ $1=="on" ] && [ $2=="1" ] – Romeo Ninov Feb 11 '15 at 19:25
  • Changing to [[ ]] just made things worse (it reads neither argument and always runs) Using [] && [] gives me the same result as [[ ]] I guess I can save myself by replacing my "on" with a "1" and using parantheses though, that helped @muru thanks :) But I'd like to know how to do this correctly with a string and number. – Cestarian Feb 11 '15 at 19:28
  • 2
    Use spaces; @muru's suggestion works well here: [[ "$1" == "on" && "$2" == 1 ]] – roaima Feb 11 '15 at 19:41
  • Thanks @roaima, quotation marks around the $1 and $2 as well as spaces between the variables and the operators were my mistake, as well as of course that I should use brackets instead of parentheses when I'm working with strings. Your example is what worked for me. – Cestarian Feb 11 '15 at 21:09

You can try this, as mentioned in comments, but note the spaces.


if [[ "$1" == "on" && $2 -eq 1 ]]; then
    echo $1 $2
    echo failure
  • == is not the way to compare numbers! – Romeo Ninov Feb 11 '15 at 19:52
  • Sorry, corrected it. – taliezin Feb 11 '15 at 20:01
  • Thanks, I managed to figure it out thanks to this comment. The problem was that I didn't put quotation marks around the $# vars, (so $1 instead of "$1" like in your example) And after that, the problem was that after the quotation marks were added, I needed to create a space between the "$1" and == and "on". In your example you failed on the spacing between the strings and the operator, but otherwise it worked correctly for me. If you fix it by adding the spacing I'll mark your answer as the solution :) – Cestarian Feb 11 '15 at 21:07
  • If you're using [[, you should change the she-bang to be #!/bin/ksh or #!/bin/bash. There's no [[ in the standard sh language. In sh, you'd write [ "$1" = on ] && [ "$2" -eq 1 ]. – Stéphane Chazelas Feb 11 '15 at 21:28
  • I edited, should I change the whole answer? – taliezin Feb 11 '15 at 21:41

Double parentheses are for numeric operations; square brackets [] act like boolean contexts. Double square brackets aren't portable, and will fail in dash and other very minimal shells. In reality, [ is a shell builtin/POSIX utility that performs logical operations, which is why you need spaces around them. This link has a lot more detail on the topic if you're curious.

If I were to write this, it would look more like this:


# check we got the expected number of arguments
if [ "$#" -ne 2 ]; then
  echo USAGE ...

if [ "x$1" = "xon" ] && [ "$2" -eq 1 ]; then
  echo "$1 $2"
  echo failure

The "x" concatenation is good practice to prevent empty strings from derailing your program.

  • An empty string is always a valid string. That's what the "" are for. The x concat is from crippled operating systems. – ott-- Feb 11 '15 at 21:06
  • 1
    the problem x tries to address is not about empty strings. It's about problems with values of $1 like ! or -f in pre-POSIX shells. It's not needed in modern systems. – Stéphane Chazelas Feb 11 '15 at 21:31
  • The two separate tests [ ... ] && [ ... ] can often be replaced with the one [ ... -a ... ] – roaima Feb 11 '15 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.