-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/01/16 19:53, Matthew Allen wrote: > It seems that sqlite3.exe (console) doesn't work as a subprocess > with pipes.
There is a bit of a problem with using apps via pipes. Generally when stdout is a terminal, output will be line buffered (ie you get each line from printf as \n is encountered). However when output is not a terminal then other buffering kicks in. For example it may be in blocks of 4kb, so you'll only see something every time that much has been generated. The Windows standard library is even a bit stranger when not connected to a terminal. For the first 512 bytes of output it will send them immediately, and then switch to block buffers. There are solutions available to try and "trick" the apps to believing they are outputting to a terminal, when it is in fact a pipe. However you won't need them (but shoutout to Expect - a populariser of TCL). > while p.poll() == None: resp = p.communicate() print len(resp[0]), > resp[0] That code doesn't make sense. communicate waits until the process terminates. The SQLite shell won't terminate unless it gets a quit command, or EOF on stdin. > The problem I'm trying to solve is: When my application that uses > an sqlite3 database gets the "database disk image is malformed" I > need to be able to give the user a "repair" option which dumps the > datrabase to an .sql file and reimport it all. I'm assuming the > best way is to do that via the shell rather than try and copy all > the dump code into my own application. Good news - here is a shell in Python I already made for you: https://rogerbinns.github.io/apsw/shell.html#shell-class https://github.com/rogerbinns/apsw/blob/master/tools/shell.py It does require APSW for the database access, as the standard sqlite3 module lacks various functionality. https://rogerbinns.github.io/apsw/pysqlite.html You can add your own repair command based on the existing dump command. This shell aborts on error. The way the standard SQLite shell handles errors (IIRC) is to scan a table forwards (rowid order), and then on encountering the error scans backwards. This is a best effort, but doesn't mean you won't lose lots of data! However I'd recommend you use the backup api and make periodic copies of the database that way. You can then offer going back to a previous snapshot. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlaZU68ACgkQmOOfHg372QTvegCgpF/pck6KCjdOqDKhxl5XEyuA cFYAoMdJwpDo5Pwg2uRr/RbNYmEhtdz1 =AR0i -----END PGP SIGNATURE-----
