Joe Wilson wrote:
--- [EMAIL PROTECTED] wrote:
Joe Wilson <[EMAIL PROTECTED]> wrote:
--- John Stanton <[EMAIL PROTECTED]> wrote:
Sqlite3 will get into a tangle with certain sequences where it does not
accept a semicolon as a terminator or obey a CTL c.
To reproduce:
1. build sqlite3 without readline support.
2. run sqlite3 in an xterm
3. at the prompt, press cursor up
4. hit return
Nothing you do at this point will work except for Ctrl-\ to kill the process.
SQLite version 3.4.1
Enter ".help" for instructions
sqlite> ^[[A
...> .q
...> ;
...> select 1;
SQLite allows identifiers to be quoted using square brackets.
Like this: CREATE TABLE [alpha]([beta],[gamma]);
In the input above, SQLite sees the beginning of a quoted
identifier in the "[A" but it never sees the terminating "]"
so it keeps asking for more input. It things the semicolons
you are feeding it are part of the identifier.
To break out of the loop, enter "];".
Works as designed....
It makes sense in hindsight. Even though [] would be an illegal first
token in any shell or SQL command, you only attempt to tokenize/parse the
line when you get to the end of statement ";". Would incremental
tokenizing/parsing be easy to implement to catch this case?
Lucky in this case I happened to be running in an xterm that echoed
the ^[[A characters. Other terminal programs I've used (such as rxvt on
cygwin) doesn't print the ^[[A to the screen at all, but instead moves
the cursor up one line. In that case it is not obvious what is going on,
or that ]; will take you out of that mode. I guess the user just has to
know a little about terminal ascii escape sequences and sqlite token syntax.
It didn't cross my mind that this effect could be an artifact of the []
delimiters. What xterm echoes should have been a clue.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
