I am trying to escape single quotes in parameters that are passed to a Bash script which is run on Jenkins. I am wondering if there is a way for me to escape these single quotes through Jenkins, or do I need to change the code to escape them.
I have already tried passing parameters like you're or we've, by doing this: you\'re as well as you\'\re but the Jenkins job automatically fails, but youre and weve works just fine. I can try running this manually in the command line and escaping the apostrophes there, however, I would like this process to be simplified.
"sed -ie 's/lms.facebook.keywords=.*\$/lms.facebook.keywords=${KEYWORDS}/g'
The parameters being passed to Jenkins become populated in: ${KEYWORDS}.
When trying to pass a parameter that has an apostrophe, the job automatically fails and returns this:
bash: -c: line 8: unexpected EOF while looking for matching `''
bash: -c: line 11: syntax error: unexpected end of file
Build step 'Execute shell' marked build as failure
Finished: FAILURE
When you are passing the Jenkin's parameter you're
use double quotes for that variable
like
"$apostrophes"
String concatenation in shell script works with double quotes.
"sed -ie 's/lms.facebook.keywords=.*\$/lms.facebook.keywords="${KEYWORDS}"/g'"
Related
I have a simple script that i need for my pipeline :-
sh '''podname=$(kubectl get pods -n my-namespace --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep my-pod)
echo "my name is $podname"'''
All i need to invoke through my jenkins declarative pipeline is the value of that kubectl command that i can use later in my script. If i run the same directly on the linux server it works just fine, but somehow through groovy shell invocation always results in syntax errors with respect to unterminated quotes, illegal dollar literal, etc.
How do i fix this?
The syntax looks fine to me, except for this, in the middle of the command:
"\n"
This will be interpreted as an actual new-line, which may not be what you want? Perhaps try this instead, to let the \n sequence be passed to the command:
"\\n"
If that still doesn't help...
according to the docs:
Runs a Bourne shell script, typically on a Unix node. Multiple lines are accepted.
An interpreter selector may be used, for example: #!/usr/bin/perl
So another suggestion is to try adding the appropriate shebang to your script... as there's no reason the result should be different from when you run this on the shell.
I'm running into an issue with command substitution that I'd like help with. I have a few processes that create a text file with commands that need to be executed.
File1.txt
Command_ID|Command_Name|Command
112121|Export XML Components|/Scripts/Export_XML.sh "Argument1" "Argument2"
112122|Test XML integrity|/Scripts/Test_XML.sh "Argument1" "Argument2" "Argument3"
My Script to execute these commands reads File1.txt and tries to execute the command in the third column using the following Command substitution. The goal here is to read and execute the commands sequentially and update a table with their return strings and return codes. I also have logic in the script to stop processing if a non-zero return code is encountered and store the current line number. This way the script can be restarted from the failed line after the issue has been addressed
VAR_File=/files/File1.txt
while IFS=$'|' read -r -a myArray
do
echo "${myArray[2]}"
VAR_Command="${myArray[2]}"
VAR_Return_String=$("${VAR_Command}")
VAR_Return_Code=$?
done < ${VAR_File}
The commands where the Arguments have double quotes are not being executed correctly.
What am I doing wrong and how can I fix this?
Thanks
In your script, VAR_Command is set to some string from File1.txt like /Scripts/Export_XML.sh "Argument1" "Argument2".
When running $(${VAR_Command}" with this string, the shell attempts to execute a script named Export_XML.sh "Argument1" "Argument2" (with quotes inside the file name), rather than the script Test_XML.sh to which the arguments "Argument1" and "Argument2" are passed.
If you remove the quotes by replacing $("${VAR_Command}") by $(${VAR_Command}), your code will work as expected.
I run with the file with command line arguments:
samplebash.bsh fakeusername fakepassword&123
.bsh file:
echo "Beginning script..."
argUsername='$1'
argPassword='$2'
protractor indv.js --params.login.username=$argUsername --params.login.password=$argPassword
Output:
Beginning script...
123: command not found
The Issue: For some reason, it interprets what follows the & symbol from the password as a command, how do I avoid this?
The problem isn't happening in your script, it's happening in your original command line. & is a command terminator, which specifies that the command before it should be executed in the background. So your command was equivalent to:
samplebash.bsh fakeusername fakepassword &
123
You need to quote the argument to prevent special characters from being interpreted by the shell.
samplebash.bsh fakeusername 'fakepassword&123'
Also, you shouldn't put single quotes around a variable like you do in your assignments, that prevents the variable from being expanded. So it should be:
argUsername=$1
argPassword=$2
And you should put double quotes around the variables when you use them in the command, to prevent wildcards and whitespace from being interpreted.
protractor indv.js --params.login.username="$argUsername" --params.login.password="$argPassword"
As a general rule, you should always put double quotes around variables unless you know they're not needed.
I'm in a PowerShell console session, trying to run a Gradle script that exists in the cwd from the PowerShell command line.
The Gradle command accepts an argument which includes quotes that can contain one or more pipe characters, and I can't for the life of me figure out how to get PowerShell to escape it using just one line (or any number of lines, actually - but I'm not interested in multi-line solutions).
Here's the command:
./gradlew theTask -PmyProperty="thisThing|thatThing|theOtherThing"
...which produces this error:
'thatThing' is not recognized as an internal or external command, operable program or batch file.
I've tried all of these variants, none of which work. Any idea?
./gradlew theTask -PmyProperty="thisThing`|thatThing`|theOtherThing"
./gradlew theTask -PmyProperty=#"thisThing|thatThing|theOtherThing"
./gradlew theTask -PmyProperty="thisThing\|thatThing\|theOtherThing"
./gradlew theTask -PmyProperty="thisThing\\|thatThing\\|theOtherThing"
./gradlew theTask -PmyProperty="thisThing^|thatThing^|theOtherThing"
Well, I have found that:
First call your script like this as I first suggested:
./gradlew theTask -PmyProperty="thisThing^|thatThing^|theOtherThing"
Then modify your gradlew.bat script by adding quotes:
set CMD_LINE_ARGS="%*"
The problem is: now CMD_LINE_ARGS must be called within quotes or the same error will occur.
So I assume that your command line arguments cannot be something else and I'm handling each parameter one by one
rem now remove the quotes or there will be too much quotes
set ARG1="%1"
rem protect or the pipe situation will occur
set ARG1=%ARG1:""=%
set ARG2="%2"
set ARG2=%ARG2:""=%
set ARG3="%3"
set ARG3=%ARG3:""=%
echo %ARG1% %ARG2% %ARG3%
The output is (for my mockup command):
theTask -PmyProperty "thisThing|thatThing|theOtherThing"
The "=" has gone, because it has separated parameters from PowerShell. I suppose this won't be an issue if your command has standard argument parsing.
Add as many arguments as you want, but limit it to 9 anyway.
Found another possibility here. One can use single quotes and double quotes like this. Not sure if that helps to solve the original problem but it helped to solve mine.
'"thisThing|thatThing|theOtherThing"'
I have this command in a unix Bash Shell Script:
midori http://www.test.com/test.php?id=$i&test=yes#test(test) &
But I get:
syntax error near unexpected token `('
How do I use this?
As commented, this should make it:
midori "http://www.test.com/test.php?id=$i&test=yes#test(test)" &
Note that giving the parameter within double quotes makes midori understand it as a string. As you were giving it without any quote, bash was trying to interpret it and getting puzzled with the ( in (test).