> Not a bug.
Im sorry, but to me it is still looks like a bug.
> The single-quotes on the argument are being stripped off by the CLI itself
No, it is wrong assumption. Let debug what shell did:
```
#!/bin/bash -x
echo "
some 'quoted' stuff
"
```
as you can see:
```
+ echo '
some '\''quoted'\'' stuf
'
some 'quoted' stuf
+ exit
```
the shell kept single quotes as it is in my original posting, so it is the same as you suggested: "'xxx'"
Let get rid of operation system's shell at all and run sqlite3 shell directly:
```
sqlite> .parameter set @a '+1+2+3'
sqlite> select @a;
6
```
Why the sqlite evaluating enclosed in single quotes data at all ?
If one will do workaround by double quoting as
```
sqlite> .parameter set @a "'+1+2+3'"
```
then first of all, it is very confusing and second it's breaking the rule that double quotes allowed only to identificators only, such as table or column names and single quotes for using on STRING data (which is the case for my example)
In anyone unix's shell, stuff enclosed in a single quotes supposed to be a raw data and must be kept as it is.
The only unquoted parameter in my original example is **`${block}`** and intentionaly passed unquoted to assist sqlite to evaluate it to "1" or "0" from "TRUE" or "FALSE" instead of treating it as a string.
I don't really understand, why sqlite3 trying to evaluate quoted value at all, especially on assigning to prepared statement ?
Why this works as expected:
```
sqlite> select '2+2';
2+2
```
but in most critical operation from the point of security - in prepared statement assignment, sqlite trying to be smart and converts itself into calculator?
If user supplied data going to be evaluated by database engine, then it isn't prepared statement, but pandora box IMHO.