Thank you Larry for taking time to look into the issue! > 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. Could you please test solution you proposed above on your side in **`sqlite3`** shell to be make sure it is not something wrong in my local settings (on linux, freebsd and all zoo of windows): ---- ``` sqlite> .param init sqlite> .param set @var \'a b c\' ``` ---- > And to get a '\' character through your sh script, the '\' will need to be doubled. BTW, there no need to double escaping (or double escaping) single quotes in **`sh`**, **`dash`**, **`bash`** and so on, if one passing single quotes enclosed in double quoted string. You can use shell's debug option **-x** to see how shell threats this character. ``` #!/bin/bash -x echo "some 'quoted' text" ``` Single quotes passing as literal characters and don't need to be escaped: ``` + echo 'some '\''quoted'\'' text' ``` since shell already did escaping for us. > And that parsing is not a bug, certainly not now after many years of stability and presumable reliance by other users. Do you mean that **SQLite** haven't any bugs ??? Then run please **sqlite3** shell. **Interactively.** And issue following `.dot commands`: ``` sqlite> .param init sqlite> .param set @vvv '+1+2+3' sqlite> select @vvv; ``` > Submitted SQL is subject to no parsing by the SQLite shell; it is passed to sqlite3_prepare as written. If it's prepared statement and passed into "sqlite3_prepare **as written**", then it should pass it with singles quotes and then **sqlite** engine will treat it in the same way as ``` SELECT '+1+2+3'; ``` but **.dot command** **.parameter** stripping single quotes in a shell code and that became **not a prepared statement** at all. Using proposed by Richard workaround<br> **sqlite> .param set @vvv "'+1+2+3'"**<br> sorry, but is not intuitively understandable why to do it, especially if this shell's behavior isn't documented. > And that parsing is not a bug, certainly not now after many years of stability and presumable reliance by other users. Larry, we are in the same boat and I pretty sure that you know that there no ideally perfect programs. If no one didn't stepped on a bug for a long time, it doesn't means there no bugs, and that's Ok, nobody perfect. Microsoft and linux periodically discovering bugs that are a few decades all even the whole world using it. I know, that many users claims that they found a bug usually boiling down to either user's error or misbehaving of third party tool that uses sqlite, but issue I talking, is in SQLite3 shell. The whole point of .dot command **.param** is to emulate prepared statement to be make sure value will be passed to database engine **as is**, without modifications and what is **most important** - without trying to evaluate content(!!!).