a shell scripting quirk, .quit maybe, or .exit?
(1) By Larry Brasfield (LarryBrasfield) on 2020-05-14 14:50:18 [link] [source]
After encountering this quirk again recently, I decided to fix it and offer a patch. Upon reading the code, I see that it works as-is, in a funny way. Consider these example sessions:
> sqlite3 -cmd .quit
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> .q
Hmm, cannot simply quit from the invocation. (But warning about in-memory DB oddly vanished.)
> echo .quit | sqlite3
>
Workable, albeit a bit corny. Little extra typing when .quit follows other commands. Inconvenient for simple sqlite3 invocations.
> sqlite3 -bail -cmd .quit
>
Ahhh! The .quit can be done from the invocation. Was it an error?
> sqlite3 -bail -cmd .quit && echo success
success
>
Great. The -bail option really means "stop after hitting an error or when I say to stop. (And that is not an error!)"
I'm still tempted to fix it because it would reduce surprise and frustration. Logically, '-cmd .quit' should just do as seems plainly commanded. Anybody interested in a fix?
Maybe .exit works better?
> sqlite3 -cmd .exit
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> .q
> sqlite3 -cmd ".exit 1"
>
Apparently not, at least not for a non-error exit.
This post may be regarded as a scripting tip, an improvement suggestion, or an inquiry about acceptability of a patch.
(2) By L Carl (lcarlp) on 2020-05-15 18:43:01 in reply to 1 [source]
I was thinking maybe the .quit was being treated as the “end” of the command, after which it would read stdin, and a test using .read from a file seems to support that theory, but .print also does not seem to do anything, so there must be more to it than that. > sqlite3 -cmd .print "Hello World" SQLite version 3.31.1 2020-01-27 19:55:54 Enter ".help" for usage hints. sqlite> .print "Hello World" Hello World sqlite> .q