As an example,either of these will work:
db.wands.insert({"name": "Dream Bender", "creator": "Foxmond"})
db.wands.insert({name: "Dream Bender", creator: "Foxmond"})
Which one will I use any why?
You can use quotes and never have to worry about when they are necessary.
When you run a query or command from the mongo shell interface it is
being parsed by the shell's JavaScript interpreter.
Anything which isn't valid JavaScript will cause a syntax error.
For example, A collection or field name starting without an
underscore or alpha character would have to be quoted.
So, either of these will work:
db.wands.insert({"name": "Dream Bender", "creator": "Foxmond"})
db.wands.insert({name: "Dream Bender", creator: "Foxmond"})
Also, this would work:
db.wands.insert({"3name": "Dream Bender", "creator": "Foxmond"})
But this won't work.
db.wands.insert({3name: "Dream Bender", creator: "Foxmond"})
So, I find it easier to be in the habit of using quotes so you don't
have to remember the exceptions.
Related
When I try to make an __iregex call using the regular expression '^(\\. \\.)$' I get:
DataError: invalid regular expression: parentheses () not balanced
I am using PSQL backend so the django documentation states that the equivalent SQL command should be
SELECT ... WHERE title ~* '^(\\. \\.)$';
When I run this query manually through the PSQL command line it works fine. Is there some bug with Django that I don't know about that is causing this to crash?
Edit: Also, it fails for variations of this regular expression, for example
'^(S\\. \\.)$'
'^(\\. S\\.)$'
'^(\\. \\.S)$'
The solution is to replace all " " characters with \s before sending the regexp into __iregex.
I noticed while experimenting with tr///, that it doesn't seem to translate backslashes, even when escaped. For example,
say TR"\^/v"." given 'v^/\\';
say TR"\\^/v"." given 'v^/\\';
say TR"\ ^/v"." given 'v^/\\';
All of them output ...\ rather than what I expected, ....
There's some other weird behaviour too, like \ seemingly only escaping lowercase letters, but the docs page doesn't have much information... What exactly is the behaviour of backslashes (\) in transliteration (tr///)?
There is a bug caused by backslashes getting swallowed instead of correctly escaping things in the grammar for tr///.
say TR/\\// given '\\'
===SORRY!=== Error while compiling:
Malformed replacement part; couldn't find final /
at line 2
------> <BOL>⏏<EOL>
I have raised https://github.com/rakudo/rakudo/issues/2456 and submitted https://github.com/rakudo/rakudo/pull/2457 which fixes it.
The second part of the answer is that Perl 6 tries quite hard in some quoting constructs to only interpret \ as an escape for valid escape sequences, i.e. \n, \r, \s, \', etc. Otherwise it is left as a literal \.
I do not have an explanation for the observed problem. However, when you use the Perl 6 Str.trans method it looks like it's working as expected:
say 'v^/\\'.trans( "\\^/v" => "." );
Outputs:
....
Reference:
https://perl6advent.wordpress.com/2010/12/21/day-21-transliteration-and-beyond/
I'm trying to pass a quoted string through BUILD_COMMAND in ExternalProject_Add() and every way I try it's getting mangled. The code is this:
set (mylibs "-lmylib -lmylib2")
ExternalProject_Add(Foo
URL http://foo
BUILD_COMMAND make SOME_LIB=${mylibs}
BUILD_IN_SOURCE 1
...)
I've tried using backslash quotes, double quotes, inlining the whole thing, but every time, either the whole SOME_LIB=... part gets quoted or my injected quotes get escaped. Is it not possible to get quotes through to the command line so they just cover the parameters?
Even though I'm unable to get the resulting make call to look like make SOMELIB="-lmylib -lmylib2", you can make it call make "SOMELIB=-lmylib -lmylib2" which seems to do the same thing.
Have you tried quoting like this?
ExternalProject_Add(
...
BUILD_COMMAND make "SOME_LIB=\"${mylibs}\""
...
)
The outer pair of double quotes says "this is all one argument here", and the inner pair of escaped double quotes says "these are embedded IN the argument".
It may need extra escaping, though. I haven't tried this and I'm not certain it will work. But there should be a way to add escape characters until it does work... Or, worst case, you could write out a script file (bash .sh or batch .bat) that has proper shell syntax for calling make like you want it and then invoke executing the script file as the BUILD_COMMAND.
This is in response to my previous question:
PowerShell: -replace, regex and ($) dollar sign woes
My question is: why do these 2 lines of code have different output:
'abc' -replace 'a(\w)', '$1'
'abc' -replace 'a(\w)', "$1"
AND according to the 2 articles below, why doesn't the variable '$1' in single quotes get used as a literal string? Everything in single quotes should be treated as a literal text string, right?
http://www.computerperformance.co.uk/powershell/powershell_quotes.htm
http://blogs.msdn.com/b/powershell/archive/2006/07/15/variable-expansion-in-strings-and-herestrings.aspx
When you use single quotes you tell PowerShell to use a string literal meaning everything between the opening and closing quote is to be interpreted literally.
When you use double quotes, PowerShell will interpret specific characters inside the double quotes.
See get-help about_quoting_rules or click here.
The dollar sign has a special meaning in regular expressions and in PowerShell. You want to use the single quotes if you intend the dollar sign to be used as the regular expression.
In your example the regex a(\w) is matching the letter 'a' and then a word character captured in back reference #1. So when you replace with $1 you are replacing the matched text ab with back reference match b. So you get bc.
In your second example with using double quotes PowerShell interprets "$1" as a string with the variable $1 inside. You don't have a variable named $1 so it's null. So the regex replaced ab with null which is why you only get c.
In your second line:
'abc' -replace 'a(\w)', "$1"
Powershell replaces the $1 before it gets to the regex replace operation, as others have stated. You can avoid that replacement by using a backtick, as in:
'abc' -replace 'a(\w)', "`$1"
Thus, if you had a string in a variable $prefix which you wanted to include in the replacement string, you could use it in the double quotes like this:
'abc' -replace 'a(\w)', "$prefix`$1"
The '$1' is a regex backreference. It's created by the regex match, and it only exists within the context of that replace operation. It is not a powershell variable.
"$1" will be interpreted as a Powershell variable. If no variable called $1 exists, the replacement value will be null.
Since I cannot comment or upvote, David Rogers' answer worked for me. I needed to use both RegEx backreference as well as a Powershell variable in a RexEx replace.
I needed to understand what the backtick did before I implemented it, here is the explanation: backtick is Powershell's escape character.
My usecase
$new = "AAA"
"REPORT.TEST998.TXT" -Replace '^([^.]+)\.([^.]+)([^.]{3})\.', "`$1.`$2$new."
Result
REPORT.TESTAAA.TXT
Alternatives
Format string
"REPORT.TEST998.TXT" -Replace '^([^.]+)\.([^.]+)([^.]{3})\.', ('$1.$2{0}.' -f )
Comments
as per https://get-powershellblog.blogspot.com/2017/07/bye-bye-backtick-natural-line.html I'll probably use the format string method to avoid the use of backticks.
Here's the powershell 7 version where you don't have to deal with a single quoted $1, with a script block as the second argument, replacing 'ab' with 'b':
'abc' -replace 'a(\w)', {$_.groups[1]}
bc
Let's say my table is:
id text
+-----+----------+
123 | foo bar
321 | bar "baz"
Is there any way to escape those quotes around 'baz' when dumping?
My query is in the form:
SELECT text FROM aTable WHERE ...
And I would like the output to be:
foo bar
bar \"baz\"
rather than:
foo bar
bar baz
You probably want to use replace:
SELECT REPLACE(text, '"', E'\\"') FROM aTable WHERE ...
You'll need to escape your escape character to get a literal backslash (hence the doubled backslash) and use the "E" prefix on the replacement string to get the right escape syntax.
UPDATE: And thanks to a_horse_with_no_name's usual strictness (a good thing BTW), we have a solution that doesn't need the extra backslash or non-standard "E" prefix:
set standard_conforming_strings = on;
SELECT REPLACE(text, '"', '\"') FROM aTable WHERE ...
The standard_conforming_strings option tells PostgreSQL to use standard syntax for SQL strings:
This controls whether ordinary string literals ('...') treat backslashes literally, as specified in the SQL standard.
This would also impact your \x5C escape:
If the configuration parameter standard_conforming_strings is off, then PostgreSQL recognizes backslash escapes in both regular and escape string constants. This is for backward compatibility with the historical behavior, where backslash escapes were always recognized.
You can use the following incarnation of the COPY command:
COPY (SELECT * FROM table) TO ... WITH FORMAT 'CSV', ESCAPE '<WHATEVER ESCAPE CHARACTER YOU WANT>'
as described here.
You might not have to do anything, as in some cases your QUOTE option will be doubled automatically. Please consult examples for the referenced link. You can also use VALUES in addition to SELECT. No further data mangling should be necessary.
This is assuming you are using 7.3 or higher. The syntax is slightly different between 7.3 and 9.0, so please consult the appropriate docs.