Re: [sqlite] command-line shell handling of errors.
"Yes and yes." :) Alejo On 10/26/06, Kees Nuyt <[EMAIL PROTECTED]> wrote: Hi Richard, On Thu, 26 Oct 2006 17:23:17 +, you wrote: > So the question: > Who will be adversely effected by the new error behavior > in the sqlite command-line shell? Not really. I prefer the new behaviour. At the moment I have to jump through hoops and scan my make logs to detect errors and signal them. > Who is using the sqlite command-line shell in scripts in > such a way that the script will no longer work with the > new behaviors? It might break some of my scripts, but rightly so. I'll be glad to repair them. > Do I need to change the behavior back to the way it was > and provide a command-line option to provoke the new > (more rational) behavior? Not really needed, but it would be nice to have a choice to explicitly suppress errors or explicitly provoke the new behaviour, either way. As my makefiles use a macro $(SQLITE) instead of the program name itself it is easy to add any switch anyway. Your approach in the remarks of said ticket is right, in my view. Thank you for any abort-on-error solution and the beautiful, consistent product sqlite is! - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] command-line shell handling of errors.
Hi Richard, On Thu, 26 Oct 2006 17:23:17 +, you wrote: > So the question: > Who will be adversely effected by the new error behavior > in the sqlite command-line shell? Not really. I prefer the new behaviour. At the moment I have to jump through hoops and scan my make logs to detect errors and signal them. > Who is using the sqlite command-line shell in scripts in > such a way that the script will no longer work with the > new behaviors? It might break some of my scripts, but rightly so. I'll be glad to repair them. > Do I need to change the behavior back to the way it was > and provide a command-line option to provoke the new > (more rational) behavior? Not really needed, but it would be nice to have a choice to explicitly suppress errors or explicitly provoke the new behaviour, either way. As my makefiles use a macro $(SQLITE) instead of the program name itself it is easy to add any switch anyway. Your approach in the remarks of said ticket is right, in my view. Thank you for any abort-on-error solution and the beautiful, consistent product sqlite is! -- ( Kees Nuyt ) c[_] - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] command-line shell handling of errors.
[EMAIL PROTECTED] writes: > So the question: Who will be adversely effected by the new > error behavior in the sqlite command-line shell? Who is > using the sqlite command-line shell in scripts in such a > way that the script will no longer work with the new > behaviors? Do I need to change the behavior back to the > way it was and provide a command-line option to provoke the > new (more rational) behavior? My use of the command line shell in scripts expects, in some cases, errors to be ignored and for the remainder of the queries to be processed regardless of the earlier errors. I agree that your proposed change would have been preferred as the original implementation. I wouldn't mind if the new behavior became the default as long as there was a new command-line option to enable backward-compatibility mode of ignoring errors and continuing to process. Cheers, Derrell - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] command-line shell handling of errors.
I don't use the command-line shell, but I'd definitely prefer not to see a fundamental change in the behavior of any tool I use. The debugging could get nasty and it's possible that someone using the tool in an unsupervised script might not notice the problem until after it had done some damage, or until the new, undesirable behavior had been taking place for days/weeks. If you make the more rational behavior a command-line option, I suspect everyone will be happier. Thanks, Alex [EMAIL PROTECTED] wrote: In previous versions of SQLite, when the command-line shell encountered an error, it would print an error message but continue processing its input. This seems wrong. In response to ticket #2045, I changed the command-line shell so that when it is reading from a file, it stops reading whenever it encounters an error. The new behavior seems more rational. But it is not backwards compatible. So the question: Who will be adversely effected by the new error behavior in the sqlite command-line shell? Who is using the sqlite command-line shell in scripts in such a way that the script will no longer work with the new behaviors? Do I need to change the behavior back to the way it was and provide a command-line option to provoke the new (more rational) behavior? For additional information: http://www.sqlite.org/cvstrac/tktview?tn=2045 -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] command-line shell handling of errors.
In previous versions of SQLite, when the command-line shell encountered an error, it would print an error message but continue processing its input. This seems wrong. In response to ticket #2045, I changed the command-line shell so that when it is reading from a file, it stops reading whenever it encounters an error. The new behavior seems more rational. But it is not backwards compatible. So the question: Who will be adversely effected by the new error behavior in the sqlite command-line shell? Who is using the sqlite command-line shell in scripts in such a way that the script will no longer work with the new behaviors? Do I need to change the behavior back to the way it was and provide a command-line option to provoke the new (more rational) behavior? For additional information: http://www.sqlite.org/cvstrac/tktview?tn=2045 -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
