Problem
I have a variable called boiler, and I want the variable si1 to be expressed, and I am unsure of how to do this in a simple and minimal fashion.
boiler='#!/bin/bash
source ../../functions.sh
current="${si1}"
ready custom
title
breadcrumbs \""$current"\" \"Options\"
# END OF BOILER (DO NOT REMOVE ABOVE CODE OR MODIFY IT)
'
ISSUE
The issue is that i want everything to be ignored withing this string (aka printed raw) except for the ${si1} variable.
EXPECTED OUTPUT
How could I concatenate the first part the variable and then the rest of the string while keeping it minimal and saving it back into the boiler variable?
You can delimit the string around ${si1}.
boiler='#!/bin/bash
source ../../functions.sh
current='"${si1}"'
ready custom
title
breadcrumbs \""$current"\" \"Options\"
# END OF BOILER (DO NOT REMOVE ABOVE CODE OR MODIFY IT)
'
This is ordinary string concatenation. The strings delimited with ' will be literal, while the string delimited with " will have the variable expanded.
Difference between single and double quotes in Bash
Related
Have been doing printf "text" to print some text from a bash script. Is using printf without a format string valid to do?
Putting the entire message in the format string is a reasonable thing to do provided it doesn't contain any dynamic data. As long as you have full control over the string (i.e. it's either just a fixed string, or one selected from a set of fixed strings, or something like that), and you've used that control to make sure it doesn't contain any unintended escape characters, all % characters in it are doubled (making them literal, rather than format specifiers), and the string doesn't start with -.
Basically, if it's a fixed string and it doesn't obviously fail, it'll work consistently.
But if it contains any sort of dynamic data -- filenames, user-entered data, anything at all like that -- you should put format specifiers in the format string, and the dynamic data in separate arguments.
So these are ok:
printf 'Help, Help, the Globolinks!\n'
printf 'Help, Help, the %s!\n' "$monster_name"
But this is not:
printf "Help, Help, the $monster_name!\n" # Don't do this
I'd like to use a variable inside a YAML literal block scalar.
Here's what I'd like to do:
markup: |
<title>
{{ title }}
</title>
Can that be done somehow?
I appreciate that this example would be trivial to execute without using a literal block scalar, but my actual use case inside a Foundation 6 stack would contain more markup and more variables than what I'm showing here.
There is no such thing as a variable inside a literal block scalar.
First of all there are no variables in YAML (the word variable, occurs only once in the YAML specification, in an example document, nr. 2.28).
And second, this is called literal for a reason. No interpretation is done of any of the characters.
Of course it is possible that some program that loads your document does something with the text between curly braces ({}). E.g interprets it as a jinja2 template. But without knowing what such a program does or expects, it is equally valid to expect something like that for the information between angle brackets (<>).
Therefore within YAML there is no way to use variables, neither inside of literal block-style scalars, nor outside them.
As for the templating: I have worked with program that generated YAML from a template and applied templates on the loaded string scalars (by recursively walking the tree). Your example could be either.
I have some data to be used to generate SQL, therefore it is important which text delimiters are used (single quotes ' delimits string literal but double quotes " delimit identifiers, at least in Oracle db).
For load procedure generator I used this
someKey: !!str 'Some SQL text'
and expected that someKey would contain the whole string including single quotes: 'Some SQL text'.
However, js-yaml.safeLoad() interprets the data as Some SQL text which is not what I wanted.
The workaround is easy, I can put the literal into additional quotes:
someKey: "'Some SQL text'"
which gives the expected result. However, I am not quite sure why in that case do we need !!str tag in YAML if it does virtually nothing (it is useful only for explicit interpretation number literals, true, false and null) and it is actually almost the same as putting double quotes around the text.
I would prefer to post this into some YAML-spec-related forum but it seems there is none.
Apart from the standard workaround, is there any trick that would do what I originally wanted, i.e. interpret any content after object key as string (+trimming off any initial and trailing spaces) without dealing with double quotes?
In YAML tag !!str is a predifened denoting a string scalar. If you specify that then even things that without that tag (or without quotes) would not be considered a string scalar, like 123, True or null.
Some string scalars need quotes e.g. if they start with a quote or double quote, if special characters need backslash espacing, or if there is a : (colon, space) in the string (which could confuse the parser to intrepret the string scalar as a key-value pair.
However putting !!str before something doesn't make it quoted (which should be obvious as it doesn't define what kind of quoting and single quoted scalars have vastly different rules from double quoted scalars).
Your workaround is not a workaround, that is just one of the ways in YAML you can specify a string scalar that starts and ends with a single quote. Another way is:
someKey: |-
'Some SQL text'
Within literal block style scalars quotes (single or double) are interpreted as is even at the beginning of the scalar. The - makes sure you don't get an extra newline after the final '
I'm working with a batch file and I was wondering, why do some variables have double quotes around them and others don't, for example?
SET "keePass=%USERPROFILE%\KeePass\KeePass-2.31\KeePass.exe"
but this:
SET name="bob"
Why the double quotes in the first one, but not the second?
...to provide the conclusion at the beginning:
Supposing you have got the command extensions enabled (which is the default setting of the Windows command prompt cmd), the best practice is to use the following set syntax:
set "VAR=value"
(The command extensions can be enabled/disabled by cmd (type cmd /? in a command prompt window for help) or, within batch files only, by setlocal (type setlocal /? for details).)
At first, let us take a look at the standard syntax mentioned in the help text, that appears when typing set /? (or help set) in a command prompt window:
set VAR=value
This assigns the string value to the variable VAR obviously.
The good thing of this syntax is:
it also works when the command extensions are disabled;
the variable value is not surrounded by quotation marks (supposing value does not contain such on its own), so there is only one place to take care of them, namely during variable expansion (like %VAR% or "%VAR%", depending on the situation at hand; this is particularly useful when combining strings like constant_%VAR% or "constant_%VAR%", which will be expanded to constant_value or "constant_value", respectively, so you always have full control over the placement of the quotation marks; if the value contained the enclosing "", constant_%VAR% would expand to constant_"value", which might probably not be the string you want to have);
But there might occur some problems:
any (invisible) trailing white-space becomes part of the string value, so if the command line is followed by a single SPACE character, VAR will carry the value valueSPACE;
when you concatenate this command with another command, like set VAR=value & echo Text, the SPACE before the & character becomes part of the value; you could of course write set VAR=value&echo Some text, but this was quite difficult to read;
if value contains special characters, like ^ & ( ) < > |, you might run into problems; for example, set VAR=1&2 will assign 1 to VAR, then an error will arise, because & separates two commands and 2 is not a valid one;
The syntax of the second example in your question is quite similar:
set VAR="value"
This assigns the string "value" to VAR, so the quotation marks are included in the value.
The advantages are:
it also works when the command extensions are disabled;
special characters (like ^ & etc.) in value do not cause any trouble because of the "";
But still:
the quotation marks become part of the value, which may be disturbing in numerous situations;
unwanted trailing white-spaces (after the last ") still become part of the string value;
again when concatenating this command with another command using &, you have to omit spaces around the ampersand;
Now, let us check out the syntax of the first example in your question:
set "VAR=value"
This assigns value to VAR. Since the quotation marks are placed around the entire assignment expression, they are removed before the assignment is actually accomplished.
This has got several advantages:
the quotation marks do not become part of the variable value;
any (unintended) trailing white-spaces do not become part of the variable value;
you can concatenate it with another command using SPACE&SPACE without any unwanted spaces being appended to the value;
special characters (like ^ & etc.) in value are no problem;
But there is one issue:
the command extensions need to be enabled for this syntax to work; otherwise, an error arises;
Finally, you could also combine the above syntaxes, if you do want the quotation marks to become part of the variable value (although I do not recommend that):
set "VAR="value""
This assigns "value" to VAR.
Advantages:
unwanted trailing white-spaces (after the last ") do not become part of the variable value;
you can concatenate it with another command using SPACE&SPACE without any unwanted trailing spaces in the value;
Disadvantages:
the quotation marks become part of the value, which may be disturbing in numerous situations;
the command extensions need to be enabled for this syntax to work; otherwise, an error arises;
special characters (like ^ & etc.) in value may cause problems; this is because of the way the command parser works: as soon as the first " is encountered, any special characters are no longer recognised, they are treated as literal characters; after the next ", special character recognition becomes re-activated, and so on; regard that this is also true in case value itself contains any quotation marks on its own;
Side Note:
Never put spaces around the equal-to sign in a set command line, because they will become part of the variable name and/or value. For instance, the command lines
set VAR = value
and
set "VAR = value"
both assign the string value SPACEvalue to a variable named VARSPACE.
I want to fetch all the strings between _(" ") from my file.
How may i fetch that?
Assuming there are no quotation marks nested within the string you're looking for, you want to load the file into a string
str=File.read("/path/to/file")
Then scan the string using a regular expression. The following regular expression should do the trick. It looks for the characters _(" (the open parentheses here is escaped, because parentheses have a special meaning in regular expressions). The next parentheses starts a capturing group (so that the text of the string will be stored in the special variable $1. Then it finds a string of consecutive characters until the first quotation mark. Then it ends the capturing group (with an unescaped close parentheses) looks for a ") to finish the expression.
/_\("([^"]*)"\)/
To use it
str.scan( /_\("([^"]*)"\)/ ) do
puts $1
end