When I use this command in Linux
systemctl --user show-environment
After one option is listed, how can I change it with command or find relevant configuration files？
Add user environment variables to $HOME/.profile.
export SOME_VALUE=the-value
For system wide changes look at /etc/profile and /etc/profile.d/.
From man systemctl:
Environment Commands
systemd supports an environment block that is passed to processes the manager spawns. The names of the variables can contain
ASCII letters,
digits, and the underscore character. Variable names cannot be empty or start with a digit. In variable values, most characters are
allowed, but
the whole sequence must be valid UTF-8. (Note that control characters like newline (NL), tab (TAB), or the escape character
(ESC), are valid
ASCII and thus valid UTF-8). The total length of the environment block is limited to _SC_ARG_MAX value defined by
sysconf(3).
show-environment
Dump the systemd manager environment block. This is the environment block that is passed to all processes the manager spawns.
The
environment block will be dumped in straightforward form suitable for sourcing into most shells. If no special characters or
whitespace is
present in the variable values, no escaping is performed, and the assignments have the form "VARIABLE=value". If whitespace or
characters
which have special meaning to the shell are present, dollar-single-quote escaping is used, and assignments have the form
"VARIABLE=$'value'". This syntax is known to be supported by bash(1), zsh(1), ksh(1), and busybox(1)'s ash(1), but not dash(1)
or fish(1).
set-environment VARIABLE=VALUE...
Set one or more systemd manager environment variables, as specified on the command line. This command will fail if variable
names and values
do not conform to the rules listed above.
Related
In the following YAML script I want to pass the IPs as a List in a terraform variable. The variable was already defined as List in Terraform code. The scope is to run this CLI inside an Azure DevOps pipeline on a Windows Agent. When running the pipeline, it fails with the following message:
Meaning that -var='ips=$(ips)' was not passed correctly.
I have also tried with -var="ips=$(ips)".
The value I am trying to assign is a text of ["123.456.111","123.456.222"]
How can I correctly pass a parameter as a List in this case?
The code where the variable ips in Terraform is used I have attached below.
- task: CmdLine#2
displayName: Terraform Plan
inputs:
script: terraform plan -input=false -out=tfplan -var='ips=$(ips)'
workingDirectory: infrastructure/terraform/dev
locals {
}
ips = tolist(toset(var.ips))
feature_flags = {
provision_vm = tobool(var.provision_vm)
provision_webapp = tobool(var.provision_webapp)
}
}
When running command line tools like Terraform it's important to be aware of which command line interpreters and other layers your command will pass through on the way to the command you are eventually running.
On a Unix system like Linux or Mac OS X your command line will typically be interpreted by a shell like bash or zsh. Unix-style shells follow the convention that the ' character marks sequences of characters to be interpreted totally literally, and so with a command line substring like -var='foo=bar baz' the shell will be the one to handle those ', removing them in the process, causing the final argument sent to the program to be -var=foo=bar baz, which happens to be the syntax that Terraform expects for this argument and so it works.
Unfortunately on Windows the conventions are rather different. Your command lines might be handled by the Windows command interpreter (cmd.exe) or by some other interpreter like PowerShell. Each has its own conventions for processing a command line, which means the same command line can be interpreted differently depending on which interpreter you are using.
For running Terraform I would suggest ensuring that you are using the Windows command interpreter if possible, because its command line processing rules are relatively simple: it doesn't interpret quote marks at all and just passes the full command line arguments into the program as a single string. However, that does mean that on Windows a command line like -var='foo=bar baz' will pass to Terraform written exactly like that, with the ' quotes still present, and thus command line parsing will fail.
Terraform on Windows follows the typical command line parsing conventions used by software written in C or using the Windows API function that parses command lines, and part of those conventions is the use of " to indicate sequences of characters where spaces should be taken literally, and so when running Terraform on Windows using the Windows command interpreter you need to enclose literal sequences of characters in " and then escape any literal " characters with a backslash, giving something like this:
-var="ips=[\"123.456.111\",\"123.456.222\"]"
Since you intend to populate this from a variable in your automation tool, this will only work if that automation tool has a mode where it'll automatically escape quote marks with a backslash, otherwise the result won't be valid.
Dealing with all of the different layers of parsing on a templated command line like this can be pretty messy, so it's often easier to instead place the variable values in a .tfvars file and then pass the filename on the command line. In that case Terraform will parse the contents of that file directly, without any interference from command line interpreters, and so you only need to deal with Terraform's own language and not the extra layered shell languages on top.
In a Linux environment I want to create a variable name with dashes. This is possible as I can set a name like that in jenkins, for which env gives the output (amongst other lines):
variable-with-dashes=test
But how can do that directly on the shell? Doing
export variable-with-dashes=test
gives an error
-bash: export: `variable-with-dashes=test': not a valid identifier
In both cases the shell seems to be /bin/bash.
I've never met a Bourne-style shell that allowed - in a variable name. Only ASCII letters (of either case), _ and digits are supported, and the first character must not be a digit.
If you have a program that requires an environment variable that doesn't match the shell restrictions, launch it with the env program.
env 'strange-name=some value' myprogram
Note that some shells (e.g. modern dash, mksh, zsh) remove variables whose name they don't like from the environment. (Shellshock has caused people to be more cautious about environment variable names, so restrictions are likely to become tighter over time, not more permissive.) So if you need to pass a variable whose name contains special character to a program, pass it directly, without a shell in between (env 'strange-name=some value' sh -c'…; myprogram' may or may not work).
https://unix.stackexchange.com/questions/23659/can-shell-variable-name-include-a-hyphen-or-dash
A name in bash shell is defined as:
A word consisting solely of letters, numbers, and underscores, and beginning with a letter or underscore. Names are used as shell variable and function names.
It's not possible to use - in names.
But how can do that directly on the shell?
I think you can write a bash builtin and in that builtin call setenv(3) to set your environment variable.
first time see such statement by exporting a variable. How to use it and what does it mean?
The : character itself doesn't mean anything on its own. An environment variable is just that - a variable, either unset or containing some value. The value is then used by another program, so what the : means depends on what program is using the variable.
Often it is used as a separator, as with the $PATH variable - you list various directories you want checked when you execute a command in a shell without specifying a full path (eg, /bin:/usr/bin:/usr/sbin - each directory is checked).
In the example you give, lib: looks like it might be a prefix of some sort. But in the end, it really depends on what will be using the variable.
Are there any rules for unix/linux shell variable naming?
For example, like the common rules for Java variable naming.
You have to be very careful not to use any UNIX command as a variable. It will mess the code and produce unexpected results. Also, keep in mind the reserved words (if, else, elif, do, done...) and that uppercase variables are reserved for system use.
From Rules for Naming variable name:
Variable name must begin with alphanumeric alpha character or underscore
character (_), followed by one or more alphanumeric or underscore
characters. Valid shell variable examples
Or as seen in The Open Group Base Specifications Issue 7:
In the shell command language, a word consisting solely of
underscores, digits, and alphabetics from the portable character set.
The first character of a name is not a digit.
I need to parse the $PATH environment variable in my application.
So I was wondering what escape characters would be valid in $PATH.
I created a test directory called /bin:d and created a test script called funny inside it. It runs if I call it with an absolute path.
I just can't figure out how to escape : in $PATH I tried escaping the colon with \ and wrapping it into single ' and double " quotes. But always when I run which funny it can't find it.
I'm running CentOS 6.
This is impossible according to the POSIX standard. This is not a function of a specific shell, PATH handling is done within the execvp function in the C library. There is no provision for any kind of quoting.
This is the reason why including certain characters (anything not in the "portable filename character set" - colon is specifically called out as an example.) is strongly recommended against.
From SUSv7:
Since <colon> is a separator in this context, directory names that might be used in PATH should not include a <colon> character.
See also source of GLIBC execvp. We can see it uses the strchrnul and memcpy functions for processing the PATH components, with absolutely no provision for skipping over or unescaping any kind of escape character.
Looking at the function
extract_colon_unit
it seems to me that this is impossible. The : is unconditionally and
inescapably used as the path separator.
Well, this is valid at least for bash. Other shells may vary.
You could try mounting it
mount /bin:d /bind
PATH=/bind
According to http://tldp.org/LDP/abs/html/special-chars.html single quotes should preserve all special characters, so without trying it, I would think that '/bin:d' would work (with)in $PATH.