Good day,
Assuming you don't want to alter the code of the shell tool to take a
named pipe (this isn't that difficult to do, unfortunately due to the
business logic I can't go into, it was not allowed):
Have you tried to create a command prompt shell, begin the sqlite
shell tool in that and direct IO to the shell? There is an occasion
(the reasoning for which I will not go into) that we do this in c#.
Yours should be able to pull the same (or similar) trick in c++.
(You should get the gist from this)
System.Diagnostics.Process pIOSql ;
pIOSql = new System.Diagnostics.Process();
pIOSql.StartInfo.CreateNoWindow = true;
pIOSql.StartInfo.UseShellExecute = false;
pIOSql.StartInfo.FileName = PathToDbDirectory + "sqlite3.exe";
pIOSql.StartInfo.Arguments = "\""+PathToDbDirectory + "my.db\"";
pIOSql.StartInfo.RedirectStandardError = true;
pIOSql.StartInfo.RedirectStandardInput = true;
pIOSql.StartInfo.RedirectStandardOutput = true;
pIOSql.Start();
pIOSql.StandardInput.WriteLine("select count(1) from
someTable;\n");
}
.....
pIOSql.StandardOutput.DiscardBufferedData();
StreamWriter sCmd = pIOSql.StandardInput;
String sqlcmd = Command;
sCmd.WriteLine(sqlcmd);
etc.
One has to do a bit of work to handle timing. If you aren't worried
(at all) about security then you could even create a temp file, and
stick your queries into it, so you can redirect your output to another
file and funnel everything through .read
Be careful about empty set results!
regards,
Adam DeVita
On Fri, Jan 15, 2016 at 8:32 AM, Dominique Devienne <ddevienne at gmail.com>
wrote:
> On Fri, Jan 15, 2016 at 4:53 AM, Matthew Allen <memecode at gmail.com> wrote:
>
>> It seems that sqlite3.exe (console) doesn't work as a subprocess with
>> pipes.
>> [...] I expect there is something funny going on with sqlite3.exe's
>> stdout/stdin.
>
>
> Sorry to highjack your thread Matthew, but I have what I consider a related
> use case.
>
> I'd like to embed the SQLite3 shell into another program, both a console
> program and a gui one,
> and because I'd like it to access in-memory databases, this cannot be done
> via forking and pipes.
>
> Basically I'd like the shell to have a "Virtual Console Interface" (VCI),
> to be able to reuse all the shell's
> goodness, in client apps, w/o having to hack and duplicate the shell's
> code. With some way to access
> in-memory databases in the same process as well (a special form of attach
> or an API?).
>
> I realize the shell is not meant and designed to be embedded right now,
> only the library is,
> but I'd really like it to be, basically. My own 2016 wishful-thinking
> feature request :). --DD
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
--
--------------
VerifEye Technologies Inc.
151 Whitehall Dr. Unit 2
Markham, ON
L3R 9T1
