Sonarqube scanner failing with "syntax error at line 16: `target=$' unexpected"

SonarQube 6.7.2
SonnarQube scanner for Jenkins plugin - 2.8.1

I have a Jenkins job that is failing when executing the SonarQube Scanner build step.

Console output below:

Any ideas why?

[Core-SonarQube] $ /home/build/tools/hudson.plugins.sonar.SonarRunnerInstallation/IL_Sonarqube/bin/sonar-scanner -Dsonar.host.url=http://sonarqube-dev.xxxxxx.com -Dsonar.projectName=Cix_Core -Dsonar.projectVersion=5.11 -Dsonar.projectKey=com.cix:core:5.7 -Dsonar.java.binaries=classes -Dsonar.sources=. -Dsonar.projectBaseDir=/home/build/workspace/SonarQube/Core-SonarQube
/home/build/tools/hudson.plugins.sonar.SonarRunnerInstallation/IL_Sonarqube/bin/sonar-scanner: syntax error at line 16: `target=$' unexpected

Hi,

There’s nothing obvious in the analysis command line you supplied to explain the error your’e getting. Could you share a little more detail about how analysis is configured in your Jenkins job?

 
Ann

I was able to resolve the issue by running the scan on a different Jenkins agent.

Hi @ganncamp,

I got the same issue and found out that the script sonar-scanner (version 4.3.0.2102 and 2.9.0.670 in my case) on linux doesn’t use the right shell interpreter or sub-command syntax.

The default shell used is sh.
Inside the script some variables has assigned values based on subcommand and the syntax used is : var=$(some command).
But this syntax is bash based. The equivalent in sh is var=`some command`.

To correct this the script must use:

  • bash interpreter
    or
  • `` sub-command syntax
1 Like

Hi @ntrauwaen,

Welcome to the community and congrats on such a valuable first post! :smiley:

I’m following up on this internally.

 
Ann

Aaaand here’s the ticket: SQSCANNER-78

 
:smiley:
Ann

I tried a few older systems but could not find one where /bin/sh did not support the $(...) syntax. /bin/sh is usually a symlink to bash, ash, dash, which all seem to support this syntax.

Can you please tell me where I can find such /bin/sh where $(...) is a problem?

I’m inclined to fix this by changing the $(...) to `...` syntax, but then I also need a way to test that the rest of the script doesn’t use some other features that are not supported in this shell.

Well, you may encounter the issue on solaris (in my case solaris 10) and any other OS where sh is not a symlink to any “modern” shell.
Technically, both syntax do the same and are POSIX. As far as I know. $() is better when dealing with nested subcommands.
If you don’t want to change the syntax, you can change the shebang and point to /bin/bash or /usr/bin/bash. But bash location will depend on the OS. Therefore you’ll have to build a script for every variations.

1 Like