Change in behavior: CLI --init

(1) By anonymous on 2020-12-12 18:01:27 [source]

As of 3.34.0, --init now reports an error if the file cannot be opened.
This creates a problem:
It used to be that to avoid all initialization (e.g. when used in a shell script), one could use:
    --init ""
That now causes an error message to be emitted (fair enough).
But there now seems to be no way to silently omit initialization.  If one uses:
    --init /dev/null
no initialization is done, but a message is emitted on stderr:
    -- Loading resources from /dev/null
which can cause problems when sqlite3 is used in a shell script.

Two suggested fixes:
  1. Do not emit "cannot open" for a blank arg to --init .
and/or:
  2. Add a --noinit option.

-- Bruce Jerrick

(2) By Keith Medcalf (kmedcalf) on 2020-12-12 18:33:17 in reply to 1 [link] [source]

Use -batch when operating in batch mode to avoid outputting status messages (in particular the -- Loading resources from ... message). -batch will not inhibit the error message if the file specified by -init cannot be opened.

That is, use sqlite3 -init /dev/nul -batch <from >to on linux or sqlite3 -init nul -batch <from >to on Windows

(3) By anonymous on 2020-12-13 06:35:51 in reply to 2 [link] [source]

Yes, thank you.  I eventually discovered that after RTFM and experimenting.
Still, a nice clean --noinit would be nice :)
-- Bruce Jerrick
PS: Minor correction, for those copying the examples you gave: It's /dev/null (two el's) on Linux.
PPS: (Again, for others.) Both --option and -option are accepted. I switched to '--' because it follows the GNU convention for "long" options.