(In regard to "useless" single-quotes and doc excerpt explaining their use:) > That's why I assumed that is isn't useless. Perhaps "needless" would be a better word. Your argument to .parameter would be the same with or without the enclosing single-quotes. In this case, they served to help disguise the problem. > > If you want to specify a text literal to that meta-command, you will need to escape the quotes > The quotes passed correctly to sqlite3 shell for sure(running bash with option -x can prove it). The issue I believe with parsing in sqlite3 shell. To be clearer: If you want to specify a text literal to that meta-command, you will need to escape the quotes from the SQLite shell's command parser so that they actually reach the .parameter command implementation. They can be prefixed with '\\' to accomplish that escaping. And to get a '\\' character through your sh script, the '\\' will need to be doubled. This need arises precisely to get the desired result through the SQLite shell's parsing. And that parsing is not a bug, certainly not now after many years of stability and presumable reliance by other users. > ... while processing regular SQL statement works as expected: ... Submitted SQL is subject to no parsing by the SQLite shell; it is passed to sqlite3_prepare as written. The parsing described in the doc section I linked is done for meta-commands (aka "dot commands") alone. If you want your expression-like text to be treated as text when .parameter finally gets it in an argument list, you can write:<code> .parameter set contact \\'+66-2-615-3964\\' </code>at the sqlite3 input prompt. Without the single-quotes, (protected from the shell's parser), that value looks like and is treated as an arithmetic expression per normal SQL rules. The .parameter implementation, as its first pass (per Richard's explanation of retry logic), places the value argument straight into a SQL VALUES() clause for a parameter table UPSERT. Only if that fails does it try single-quoting the value argument.