Re: [sqlite] SQLite3 Bug Report: The shell accepts some dot commands ending in semicolons while rejecting others.

2013-01-28 Thread Roger Binns
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/01/13 21:11, Larry Brasfield wrote:
> If anybody truly cares enough to make this behave better, it is
> encapsulated in a function named "booleanValue(char *zArg)".  For
> myself, since it takes "0" and "1", which are easy to type, the present
> behavior is entirely unobjectionable.
> 
> As for whether an appended ';' (or any other junk not called for in
> the .help output) ought to produce a diagnostic instead of simply
> following the above logic, I would say that adherence to the GIGO
> principle is perfectly adequate.

Note the change the SQLite team have made:

  http://www.sqlite.org/src/info/b4d94947fc

Roger

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlEHZEMACgkQmOOfHg372QTUTgCeOLdm5gpZQDdE6WIWZHZMzJ1M
YwIAn3AuE9RW4STFDzSU9zw0loph+nxR
=l3sT
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] SQLite3 Bug Report: The shell accepts some dot commands ending in semicolons while rejecting others.

2013-01-28 Thread Larry Brasfield

David Bicking wrote:

Actually, it looks like anything except ".header on" will turn headers off. That includes ".header 
on;" (with semicolon - it doesn't do nothing, it turns the headers off) or ".header off;" (with or 
without semincolon.) or ".header ;" (with a space and semicolon but no text.)

I could only get it to return error text with .header or .header; (no space 
before semicolon.)

.explain behaves the same way. "on;" is treated the same as "off" or "foo".

(At least with version 3.7.0 which is what I had handy to test with.)


A quick perusal of the code reveals this logic:
Any case variation of "on" or "yes", or anything that starts with a 
non-zero integer counts as "true" with regard to its effect as an option 
setting.  Anything else counts as "false".  If this was the "expected" 
behavior, it would have to be considered bug-free now.


If anybody truly cares enough to make this behave better, it is 
encapsulated in a function named "booleanValue(char *zArg)".  For 
myself, since it takes "0" and "1", which are easy to type, the present 
behavior is entirely unobjectionable.


As for whether an appended ';' (or any other junk not called for in the 
.help output) ought to produce a diagnostic instead of simply following 
the above logic, I would say that adherence to the GIGO principle is 
perfectly adequate.


--
Larry Brasfield

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] SQLite3 Bug Report: The shell accepts some dot commands ending in semicolons while rejecting others.

2013-01-28 Thread David Bicking





 From: Ryan Johnson <ryan.john...@cs.utoronto.ca>
To: sqlite-users@sqlite.org 
Sent: Monday, January 28, 2013 12:54 PM
Subject: Re: [sqlite] SQLite3 Bug Report: The shell accepts some dot commands 
ending in semicolons while rejecting others.
 
On 28/01/2013 12:08 PM, Larry Brasfield wrote:
> Nathan Chung wrote:
>> *Summary:
>> The SQLite3 shell accepts some dot commands ending in semicolons while
>> rejecting others without displaying proper error messages. The
>> behavior of the dot commands could be more consistent. Examples
>> include "header off;" and "header on;". The shell accepts "header
>> off;" while rejecting "header on;" without a proper error message.
>
> 7. There may be other dot commands displaying other inconsistent
>> behaviors. I have only verified the issue with "header on;" and
>> "header off;".
> 
> The code for the shell command decoder is not written to perform as you 
> expect.  It is very simple, (which is also a virtue), and >focused on 
> accepting correctly composed commands. The shell is considered to be a tool 
> for easily performing basic operations >upon a SQLite database, in the hands 
> of more software-savvy people than those who would be lost without detailed 
> and >"consistent" error reporting.  I dare say that said code, if modified to 
> meet your expectations, would be less suited to its purpose, >harder to 
> maintain and understand, and would divert effort from SQLite itself.  I say 
> this as one who has found reason to modify >that code and who is glad that 
> part of the task consumed little time.
>".header on;" -- does nothing
>".header off;" -- disables headers

>I'm with OP on this one. The error message doesn't need to be "helpful" -- in 
>fact I'm fine if it accepts semicolons, given that >most things you type in 
>the shell require them. Turning apparently-successful commands into no-ops is 
>never a good idea, though.

>My guess is that it's trivial to fix, especially if the decision is to allow 
>semicolons and other trailing garbage (though `.header foo' >would still 
>silently "succeed"). Probably a one-liner along the lines of 
>s/strcmp/strncmp/, or some such.

>$0.02
>Ryan

Actually, it looks like anything except ".header on" will turn headers off. 
That includes ".header on;" (with semicolon - it doesn't do nothing, it turns 
the headers off) or ".header off;" (with or without semincolon.) or ".header ;" 
(with a space and semicolon but no text.)

I could only get it to return error text with .header or .header; (no space 
before semicolon.)

.explain behaves the same way. "on;" is treated the same as "off" or "foo".

(At least with version 3.7.0 which is what I had handy to test with.)

David
 ___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] SQLite3 Bug Report: The shell accepts some dot commands ending in semicolons while rejecting others.

2013-01-28 Thread Ryan Johnson

On 28/01/2013 12:08 PM, Larry Brasfield wrote:

Nathan Chung wrote:

SQLite version: 3.6.12
OS: Mac OS X 10.6.8

*Summary:
The SQLite3 shell accepts some dot commands ending in semicolons while
rejecting others without displaying proper error messages. The
behavior of the dot commands could be more consistent. Examples
include "header off;" and "header on;". The shell accepts "header
off;" while rejecting "header on;" without a proper error message.

*Steps to reproduce:
1. Launch SQLite3 shell with a populated database and type in 
".header on".
2. Try a select statement. The retrieved table will show the field 
headers.

3. Type in ".header off;".
4. Try a select statement. The retrieved table will not show the 
field headers.

5. Type in ".header on;".
6. Try a select statement. The retrieved table will still not show the
field headers. Note that the ".header on;" command from the previous
step did not generate any error messages even though the command was
rejected.
7. There may be other dot commands displaying other inconsistent
behaviors. I have only verified the issue with "header on;" and
"header off;".


The code for the shell command decoder is not written to perform as 
you expect.  It is very simple, (which is also a virtue), and focused 
on accepting correctly composed commands. The shell is considered to 
be a tool for easily performing basic operations upon a SQLite 
database, in the hands of more software-savvy people than those who 
would be lost without detailed and "consistent" error reporting.  I 
dare say that said code, if modified to meet your expectations, would 
be less suited to its purpose, harder to maintain and understand, and 
would divert effort from SQLite itself.  I say this as one who has 
found reason to modify that code and who is glad that part of the task 
consumed little time.

".header on;" -- does nothing
".header off;" -- disables headers

I'm with OP on this one. The error message doesn't need to be "helpful" 
-- in fact I'm fine if it accepts semicolons, given that most things you 
type in the shell require them. Turning apparently-successful commands 
into no-ops is never a good idea, though.


My guess is that it's trivial to fix, especially if the decision is to 
allow semicolons and other trailing garbage (though `.header foo' would 
still silently "succeed"). Probably a one-liner along the lines of 
s/strcmp/strncmp/, or some such.


$0.02
Ryan

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] SQLite3 Bug Report: The shell accepts some dot commands ending in semicolons while rejecting others.

2013-01-28 Thread Larry Brasfield

Nathan Chung wrote:

SQLite version: 3.6.12
OS: Mac OS X 10.6.8

*Summary:
The SQLite3 shell accepts some dot commands ending in semicolons while
rejecting others without displaying proper error messages. The
behavior of the dot commands could be more consistent. Examples
include "header off;" and "header on;". The shell accepts "header
off;" while rejecting "header on;" without a proper error message.

*Steps to reproduce:
1. Launch SQLite3 shell with a populated database and type in ".header on".
2. Try a select statement. The retrieved table will show the field headers.
3. Type in ".header off;".
4. Try a select statement. The retrieved table will not show the field headers.
5. Type in ".header on;".
6. Try a select statement. The retrieved table will still not show the
field headers. Note that the ".header on;" command from the previous
step did not generate any error messages even though the command was
rejected.
7. There may be other dot commands displaying other inconsistent
behaviors. I have only verified the issue with "header on;" and
"header off;".


The code for the shell command decoder is not written to perform as you 
expect.  It is very simple, (which is also a virtue), and focused on 
accepting correctly composed commands. The shell is considered to be a 
tool for easily performing basic operations upon a SQLite database, in 
the hands of more software-savvy people than those who would be lost 
without detailed and "consistent" error reporting.  I dare say that said 
code, if modified to meet your expectations, would be less suited to its 
purpose, harder to maintain and understand, and would divert effort from 
SQLite itself.  I say this as one who has found reason to modify that 
code and who is glad that part of the task consumed little time.


--
Larry Brasfield

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] SQLite3 Bug Report: The shell accepts some dot commands ending in semicolons while rejecting others.

2013-01-28 Thread Nathan Chung
SQLite version: 3.6.12
OS: Mac OS X 10.6.8

*Summary:
The SQLite3 shell accepts some dot commands ending in semicolons while
rejecting others without displaying proper error messages. The
behavior of the dot commands could be more consistent. Examples
include "header off;" and "header on;". The shell accepts "header
off;" while rejecting "header on;" without a proper error message.

*Steps to reproduce:
1. Launch SQLite3 shell with a populated database and type in ".header on".
2. Try a select statement. The retrieved table will show the field headers.
3. Type in ".header off;".
4. Try a select statement. The retrieved table will not show the field headers.
5. Type in ".header on;".
6. Try a select statement. The retrieved table will still not show the
field headers. Note that the ".header on;" command from the previous
step did not generate any error messages even though the command was
rejected.
7. There may be other dot commands displaying other inconsistent
behaviors. I have only verified the issue with "header on;" and
"header off;".

Thank you.
-Nathan Chung
nchung...@gmail.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users