ChatGPT解决这个技术问题 Extra ChatGPT

How do I compare two string variables in an 'if' statement in Bash? [duplicate]

This question already has answers here: How to compare strings in Bash (11 answers) Closed 3 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.


B
Basil Musa

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" ]]

stackoverflow.com/a/229606/376454 I had to use this answer to compare a variable to a fixed string.
The picky guys on IRC are telling me you should use if [[ "$s1" == "$s2" ]] or case.
The double equals sign is an error in the first case. Bash tolerates it, but the portable variant is if [ "$s1" = "$s2" ]. See also Rahul's answer
Hi, I wonder why this is bad -> if ["$s1" == "$s2"] what's the point with the spaces ?
@Sangimed, [ is a command (actually, an alternate name for the command called test); if you run which [, you'll see there's actually an executable file for it on disk (even though the shell may provide a built-in implementation as a performance optimization). Just like you have to put a space between the name of the command ls before the name of the file you want it to print, you need to put a space after the name of the [ command and its first argument, and between each argument it's passed (if invoked as [ rather than test, it expects its last argument to be ]).
u
unwind

You need spaces:

if [ "$s1" == "$s2" ]

Just wanted to say to make sure to leave a space between the beginning and ending square brackets and the "$s1" == "$s2" statement or it will not work. Also, this works too: if test "$s1" = "$s2"
It's all about space :))
this first comment by @racl101 fixed the problem for me. Thanks!!
== doesn't work on ash, dash, or other places baseline POSIX implementations of test. Use = instead.
R
Robin Daugherty

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.


Many thanks for pointing out the necessary space. Solved my problem. Just started bash today, seems to be a lot of times spaces can cause an error, i.e declaring variables etc.
Bonus point for including the ; then and fi parts.
== doesn't work on ash, dash, or other places baseline POSIX implementations of test. Use = instead.
P
Peter Mortensen

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.


Upvote, but always be careful when reading the ABS. Linking to a more authoritative source would probably be preferred.
Thanks for the advice, sure a more authorative source more accurate.
/bin/sh: 1: [: missing ]
@holms, that doesn't happen with the OP's code when used precisely as given here. You'll need to show your exact usage.
P
Peter Mortensen

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

Great answer. Bet it would get more upvotes if it wasn't so far away from the top.
G
Gabriel Staples

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.


The assertion "you have to use ==" is incorrect. Bash supports both = and ==. Also, if you have #!/bin/bash at the start of your script, you can make it executable and run it like ./filename.bash (not that the file extension is important).
Perfect, I think I have to delete this answer now but it will be very helpful if you explain why this is not working without making the file executable and running by adding sh/bash before the filename?
This is confused about the significance of the shebang and the file name. If you have correctly put #!/bin/sh or #!/bin/bash as the first line of the script, you simply run it with ./filename and the actual file name can be completely arbitrary.
Now this is getting interesting,even if you don't add any shebang and any extension and execute it using "bash/sh filename" it is working no matter what you use single equal or double equals.One more thing if you make the same file(without shebang and any extension) executable then you can execute it like ./filename (no matter of single or double equals).(Tried it on Arch linux with bash 4.3.46).
If you execute the file by running say "bash filename" - then you are just passing 'filename' as a parameter to the program 'bash' - which of course will result in bash running it. However if you set 'filename' execute permission, and try to run it by eg './filename' - then you are relying on the default 'execute' behaviour of your current command shell - which probably requires the "#!(shell)" line at the start of the script, in order to work.
P
Peter Mortensen

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.


Yes that's true, I missed the spaces. With "[ $s1 = $s2 ]" it works.
Why would you omit the double quotes? They are optional but harmless in this limited specific case, but removing them would be a serious bug in many real-world situations. See also stackoverflow.com/questions/10067266/…
Try with s1='*' and s2='*', and you'll see that leaving out the double quotes is a serious mistake.
I got same behavior with = or == regardless of quotes. I'm not sure if this is shell specific, I am using zsh on my mac OS version : 10.15.7 (19H15)
q
qwerty
$ if [ "$s1" == "$s2" ]; then echo match; fi
match
$ test "s1" = "s2" ;echo match
match
$

The double equals sign is tolerated in Bash, but not in some other dialects. For portability, the single equals sign should be preferred, and if you target Bash only, the double brackets [[ extension would be superior for versatility, robustness, and convenience.
P
Peter Mortensen

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 =.


The symbol [ was a link to /bin/test at one time (or perhaps vice versa). That is apparently no longer the case on ubuntu 16.04; no idea where or when the change occurred.
P
Peter Mortensen

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 "[".


P
Peter Mortensen

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

What does it mean "more safe"? It is important to explain any such qualification, for sake of completeness and clarity.
the truth it's not safer, now I know that would be safer if you would not quote it and this way prevent syntax error if one of them was empty
P
Peter Mortensen

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.


Not bad at all. Like the explanation and the sed regexp like. I never need to use subshell that way. As i know you can get the output with command or $(command). Im sure you can TEST it then make it better.
This is trivially broken in the case where s2 contains globs: to fix this, you need to quote the expansion $s2: "${s1/*"$s2"*/0}". But there are other subtle bugs that are impossible to fix: e.g., if s1 is a list of 0's: s1=000000; s2=some_other_stuff will claim a match. So I would highly recommend against using this method! Another bug: s1=--; s2=stuff. Starting from bash 4.4, s1=--help; s2=stuff would also spam standard output.