> 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): I did that before posting. I had written, "And to get a '\\' character through your sh script, the '\\' will need to be doubled.", to which this response was made: > 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. ... Single quotes passing as literal characters and don't need to be escaped ... My comment was about the need to escape the backslash in the context of your shell script where the usual expansion within doublequotes is done on what you forumulate as the .parameter command. > > 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 ??? That's not my assertion. The parsing under discussion is occurring exactly as intended and documented, and as it has been done for so many years that we should expect to break many users' scripts if it is changed now. The opening sentence in this thread, "I believe it is a bug", expresses an opinion with which I disagree. > Then run please sqlite3 shell. Interactively. And issue following .dot commands:<code> sqlite\> .param init sqlite\> .param set @vvv '+1+2+3' sqlite\> select @vvv; </code> The SQLite shell will strip those single-quotes. I know this from my own experimentation, reading of the code that does it, and the doc I cited to you. > > 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<code> SELECT '+1+2+3'; </code>but <b>.dot command .parameter</b> stripping single quotes in a shell code and that became not a prepared statement at all. Dot commands are subject to argument parsing as documented and discussed previously. Your alleged bug is about a scenario where that parsing is leading to the result you report but did not expect. > Using proposed by Richard workaround<br> <b>sqlite> .param set @vvv "'+1+2+3'"</b><br> sorry, but is not intuitively understandable why to do it, especially if this shell's behavior isn't documented. Very little about the quoting rules could be fairly called "intuitive", but it <b><u>[is documented](https://sqlite.org/cli.html)</u></b> where and as I cited earlier in section 4. I think the time has come for you to read it, carefully. Richard's solution will work at the SQLite shell command line because the outer double-quotes serve to protect the argument, retaining its single-quotes. I did not propose it because the double-quotes would have to be escaped in your sh program, but so do the protective backslashes. Either way it becomes one of the multi-layered quoting tangles that sh programmers love or dread. Regarding the discussion of perfect programs and lack thereof: I respectfully disagree but decline to participate in hijacking this thread along such lines.