I have a secret var :
But when I do - echo %MySecretVar%, runner displays foo only
How can i escape special chars like ! in Gitlab Secret Vars ?
I had the same problems with Gitlab, job running on windows, but I assume it will reproduce on Linux as well, because it seems Gitlab parsing issue or relay weird escaping.
So I have set environment variable
APPPOOL_PWD: 'blabla!foo$bar'
and output of echo %APPPOOL_PWD% or echo $APPPOOL_PWD was 'blabla'
The Gitlab seems to be was eating out the exclamation mark sign ! and dollar sign $. To avoid it as proposed in comment for exclamation mark I have used ^^ and for dollar sign I have used $$ as proposed in the Gitlab variables documentation.
So following variable works well:
APPPOOL_PWD: 'blabla^^!foo$$bar'
and output of the echo command in this case would be 'blabla!foo$bar'.
I was able to use a value with special characters this way:
Define Gitlab CI variable FOO with special characters in the value, e.g. ?!asdf&%fghjkl
In .gitlab-ci.yml define:
variables:
bar: '"%FOO%"'
script:
- echo %bar%
This way the variable will stay exactly the way it is typed in your CI variable field.
I'm using Windows batch shell. If you use another shell for script running, the syntax is a little different from %bar%. Check out the syntax here: Gitlab CI reference
I am using GitLab 15.3.3-ee and I don't see any issue with the ! it get's passed through. However for $ you will have to use extra $ as escape character, just like mentioned in the first comment.
Related
I have a Environment Variables:
"PWD=uNfob$bA5052433"
When I print PWD out it always:
'uNfob'
I have tried :
'PWD=uNfob$bA5052433'
or
PWD='uNfob$bA5052433'
all not work,any suggestion ?
This works for me:
VAR='aaa$bbb'
echo $VAR
aaa$bbb
PWD is a special shell variable that represents the current directory. You might want to use someting else.
I solved it by 2 steps:
1.use single quotes 'PWD=uNfob$bA5052433'
2.add '/' 'PWD=uNfob/$bA5052433'
I'm executing git ls-remote ssh://git#git_repo:port * in two different computers under same network, one Linux another Windows, and on Windows I'm getting the list but on Linux not. No error at all just and empty list on Linux.
Both has the SSH key added to the remote repository and both are able to clone the repository.
Update 1:
Windows Git version: 2.19.2.windows.1
Linux Git version: 2.7.4
Update 2:
The repository is in Gerrit.
Update 3:
I'm facing this problem using the Jenkins plugin Extended Choice Parameter plugin. It has no change since 2016. Any workaround for this would be also an answer.
Any idea?
You probably should use:
git ls-remote ssh://git#git_repo:port
without any suffix, as it defaults to listing everything.
You can use:
git ls-remote ssh://git#git_repo:port '*'
(or the same with double quotes—one or both of these may work on Windows as well). In a Unix/Linux-style command shell, the shell will replace * with a list of all the files in the current directory before running the command, unless you protect the asterisk from the shell.
You can also use a single backlash:
git ls-remote ssh://git#git_repo:port \*
as there are a lot of ways to protect individual characters from shells. The rules get a little complicated, but in general, single quotes are the "most powerful" quotes, while double quotes quote glob characters1 but not other expansions.2 Backslashes quote the immediate next character if you're not already inside quotes (the behavior of backslash within double quotes varies in some shells).
1The glob characters are *, [, and ?. After [, characters inside the glob run to the closing ]. So echo foo[abc] looks for files named fooa, foob, and fooc. Note that . is generally not special: foo.* matches only files whose names start with foo., i.e., including the period: a file named foo does not start with foo., only with foo, and is not matched.
Globs are very different from regular expressions: in regular expressions, . matches any character (like ? does in glob) and asterisk means "repeat previous match zero or more times", so that glob * and regular-expression .* are similar. (In regular expression matches, we also need to consider whether the expression is anchored. Globs are always anchored so that the question does not arise.)
2Most expansions occur with dollar sign $, as in $var or ${var} or $(subcommand), but backquotes also invoke command substitution, as in echo `echo bar`.
I am trying to do string substitution in bash, want to understand it better.
I crafted a success case like this:
a=abc_de_f
var=$a
echo ${var//_/-}
outout is abc-de-f. This works.
However, the following script fails:
a=abc_de_f
echo ${$a//_/-}
The error message is ${$a//_/-}: bad substitution.
It seems like related to how we can use a variable in substitution. Why this fails? How bash handles variables in this case?
Also, what is the best practice to handle escape characters in bash string substitution?
In the second case, you don't need the second $ as a is the string.
a=abc_de_f
echo ${a//_/-}
If you wanted to add a level of indirection, you can use ! before the variable as in
a=abc_de_f
b=a
echo ${b//_/-}
will output a, while
echo ${!b//_/-}
will output abc-de-f.
See here for a discussion on the art of escaping in BASH
I'm trying to run a command while injecting a variable which has quotes, but bash keeps adding extra quotes which I don't need and falsifies the process...
this is my example:
set -x
MYVAR=" --name='user should login' "
cucumber $MYVAR
this results into running this:
cucumber '--name='\''user' should 'login'\'''
and the command fails. However, when I run cucumber --name='user should login' as is, without using variables, everything goes as expected.
PS. same result with cucumber "${MYVAR}" or cucumber "$MYVAR"
It is better to use BASH arrays for storing command lines:
myvar=(--name 'user should login')
cucumber "${myvar[#]}"
I've also lowercased your variable as using all UPPER case variables can be problematic sometimes.
This works, with no bashisms:
MYVAR=" --name='user should login' "
eval cucumber $MYVAR
I'm trying to run the Apache startup script, /etc/init.d/httpd. Environment variable definitions like this one give an error:
CONF_FILE=$(APACHE_HOME)/conf/httpd.conf
It says "/etc/init.d/httpd: line 15: APACHE_HOME: command not found"
So, I replaced the parentheses with curly brackets, and the script worked swimmingly. What gives? I'm really just asking this question because I want to understand why it's wrong, not how to fix it. The shebang is there, and it's unmodified from the original shell script, so why's it misinterpreting things?
In unix systems:
$SOMETHING /* variable */
$(SOMETHINGELSE) /* command */
${FOO} */ variable substitution */
$(...) executes its contents in a subshell, it doesn't get the value of a variable. You can use just plain $APACHE_HOME or ${APACHE_HOME}, which it sounds like you switched to.
$(something) tells the shell to execute command something and substitute the command's output.1
You want to substitute a variable's output, so you just need a $ in front of the variable, like so: CONF_FILE=$APACHE_HOME/conf/httpd.conf
Alternatively, you could use CONF_FILE=${APACHE_HOME}/conf/httpd.conf (note the curly braces instead of parenthesis), but it's not really necessary for your situation.
1This is useful when you want to assign a command's output to a variable. For example:
MY_VAR="$(egrep 'someline' somefile.txt)"