(Edited to escape a few backslashes swallowed by markdown processing.)
> > My comment was about the need to escape the backslash in the context of your shell script where the usual expansion within double quotes is done on what you forumulate as the .parameter command.
> Let leave my script out of discussion, Im pretty sure my code works as expected and passing exact values to sqlite3. I showed test cases in interactive mode of sqlite3 which show the issue.
I'm agreeable to that. However, I will likely continue to remind people whose shell scripts are producing unexpected results that sh, ash, bash, csh, dash, fish, ksh or zsh have a say in what reaches other programs.
> ... I just reporting bug/feature issue that isn't documented ...
As I have said (and linked twice) and someone else mentioned, the quoting behavior of the shell's command line parser is documented.
> ... IMHO, there in documentation no any clue that shell will try to evaluate user supplied value ...
We're getting into semantics here. By "the shell", I (and other forum participants) generally mean the CLI program named sqlite3 or sqlite3.exe which contains an instance of the SQLite library, and interprets command line input as either meta-commands or as SQL to be submitted to the library for execution.
The .parameter meta-command is doing some of both. It accepts a set of input arguments as parsed by the shell, and for the "set" subcommand it composes some DDL with this code:<code>
zSql = sqlite3_mprintf(
"REPLACE INTO temp.sqlite_parameters(key,value)"
"VALUES(%Q,%s);", zKey, zValue);
</code>and submits it to the library. Note that the 2nd value in the VALUES clause, passed to sqlite3_mprintf() as zValue, is not quoted in any way; it is incorporated into the statement as it was given to this code by the meta-command parser. If somebody wants a blob literal, they can have one put into the parameters table. Or whole SELECT statements involving values taken from other tables could be passed in as the value.
Using a shell build from the cli_extension branch, (with SQLITE_GIMME_SEEARGS #define'd), I created this screen-scrape:<code>
larrybr@Bit-Bungler:~/SQLite/SqliteLib/ShellMods$ ./sqlite3
SQLite version 3.38.0 2022-01-08 21:59:49
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite\> .seeargs set @vvv '+1+2+3'
set|@vvv|+1+2+3
sqlite\> .seeargs set @vvv \\'+1+2+3\\'
set|@vvv|'+1+2+3'
sqlite\> .param init
sqlite\> .param set @noquotes '+1+2+3'
sqlite\> .param set @quoted \\'+1+2+3\\'
sqlite\> .header on
sqlite\> select * from temp.sqlite_parameters;
key|value
@noquotes|6
@quoted|+1+2+3
sqlite\>
</code>, which enables fairly direct observation of what meta-command implementations will see. Note carefully how the @quoted and @noquotes parameter values were affected. The evaluation of that multi-term expression when unquoted happened as the DDL formed by the .parameter set code was evaluated by the library. We could argue for a long time whether this evaluation is done by "the shell" or by "the library", but to no avail. The bottom line, however you characterize this behavior, is that, in order to get text which looks like an arithmetic expression into the parameters table <b>as text</b>, you will have to get some single-quotes around it as it is passed to the above code.
The thrust of my suggestions has been how to get those single-quotes past the meta-command parser and to the .parameter implementation.
That all said, I can see that the doc for the .parameter meta-command should make clear how and when its arguments are evaluated. The doc vaguely mentions "value of the value column" (referring to the parameters table), but says too little about how those values get there. I will improve upon that soon.
> Call me nitpicker, but parsing != evaluation
I would perhaps consider calling you a nit-picker if I had made an assertion to the contrary. As I have not, but have focused on parsing (except where I mentioned earlier what ".parameter set ..." does), I'll just say that this discussion has enough red herring content already.
> If it is says parameter key value then the value must be a raw value, as is. There no in documentation anything that it says that value can be a math expression and this expression will be automatically evaluated.
> > ... it becomes one of the multi-layered quoting tangles ...
> I don't agree, the code below can live without ugly escaping ...
Your shell code's HERE string is not subject to variable expansion as you will see if you examine its effect. Your original post relied on variable expansion to (attempt to) get a value from a sh variable into that parameters table. Given that context for my "it becomes" assertion, your disagreement is truly an instance of nit-picking.
> ... If the word "bug" is unwelcome, Im fine with it as long as the issue resolved.
There is no bug here. There is a document ambiguity which can be improved so that the next person experiencing your difficulty can be told: "Read the docs, here." The action you need to take should be clear at this point. (Get a pair of enclosing single-quotes to the .parameter set subcommand.) I see no need for any further meta-commands when, with a better understanding of the existing ones, users can accomplish what the suggested new meta-command would do.