Re: [sqlite] extension to run bash

[James K. Lowden]

On Thu, 12 Jan 2017 01:54:28 +
Roman Fleysher  wrote:

> From bash script, make list of rows, run commands, load results to
> sqlite. Or
> 
> From sqlite, use extension to run commands for each row.
> 
> Both have issues.

You will find your shell script faster.  The more files, the more it
matters.  That's because (presumably) your script invokes wc(1) once,
and that process iterates over the filenames.  The longer your
pipeline, the more the process is parallelized, too.  

You could also use make(1) to maintain aggregate counts.  Imagine
roughly a rule like this:

.txt.N:
wc $^ > $@

Re-run make at convenient intervals, and let it determine which counts
are out of date.  The more files, the bigger, and the more static they
are, the more make saves you.  

If you use an extension, every row gets a process.  If you use 
system(3) instead of exec(2), every row gets two processes.  Each row's
process (or two) has to run sequentially.  That will add up.  

The advantage of the extension is that it's a "view"; the data are as
good as the time the query is run.  (We're giving up atomicity, because
nothing prevents the files from being changed as the query runs.)  

To make the extension faster -- as fast as the script would be -- you
can't run one process per row.  Instead, implement wc(1) as a C
function, and create a wc extension.  Instead of writing the code
yourself, I'd steal an implementation.  NetBSD's wc.c is 354 lines,
half of which is copyright & UI.  

A "wc" extension would be simpler than a "system" extension.  Once
you've written your first one, you'll find doing others is easy.
Before you know it, you'll have a little collection of /usr/bin-like
extensions that do what you need.  They'll be faster as fast as
anything the shell does (modulo parallel execution) and more convenient
because you'll do everything in SQL.  

In case it's any help, I implemented an extension a while back that
calls stat(2), cf. http://www.schemamania.org/sql/sqlite/udf/.  Look
for "File Metadata" halfway down the page.  

HTH.  

--jkl


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Warren Young]

On Jan 11, 2017, at 4:01 PM, Jim Callahan  
wrote:
> 
>> How much doing all that is worth is a different question, since the calls
> made through this
>> proposed system() SQLite function would also likely be non-portable.  In
> this very example,
>> there is no wc on Windows.
> 
> I would suggest renaming the proposed system() function bash()

Definitely not.  Bash is not the only shell on POSIX systems, and system() or 
popen() on such systems may or may not be calling Bash to do their work.

You also have the Windows option I brought up in my previous post; you wouldn’t 
want to have to write a separate function called cmd() that only worked in 
SQLite SQL when run on Windows.

I would suggest not calling it system().  C’s system() doesn’t work like the 
proposed SQLite extension: you don’t get a way to capture the output.  Calling 
it popen() also doesn’t seem right.

Something like cmdsubst() seems more accurate.  (Named after the POSIX “command 
substitution” feature, which is what this proposed function would actually 
provide.)

> now and in the future there may be different command line shells.

Sure, but naming the function bash() implies that the function would have to be 
changed somehow to operate with these other shells.  That’s not how POSIX 
systems work: system() and popen() on POSIX systems use an 
implementation-defined POSIX shell, which may or may not be Bash.

You shouldn’t care what shell system() and popen() use underneath.  As long as 
you give it a command in valid POSIX shell syntax, it should run correctly 
everywhere the referenced external commands exist.

> The (now) new Windows 10 Anniversary Edition has the option of installing a
> shell that nearly runs Canonical Ubuntu Linux's BASH shell.

There are severe limitations to depending on that besides the fact that it 
isn’t installed by default.

While you can run “bash -c 'some command'” from a native Windows executable and 
capture its output, what happens inside the Bash environment under WSL is 
largely firewalled off from the regular Windows environment except for I/O 
interactions.  (i.e. disk files, network traffic, etc.)

So for example, you couldn’t use WSL’s bash.exe via this SQLite extension to 
detect whether notepad.exe is running:

cmdsubst('pgrep notepad.exe')

WSL has a separate process table from the native Windows one, so the pgrep 
running under WSL can’t find notepad.exe, even if it is running.

> In a few years
> it will likely be a routine part of Windows.

I doubt it.  You have to turn off a bunch of security mechanisms in Windows to 
get it to run.  (So-called “developer mode.”)

Unless they find a way to allow WSL to run without needing developer mode 
privileges, installing WSL by default would effectively roll back all those 
protections for everyone.

> Thus, at some point, Linux, OS/X and Windows will all support Bash scripts.

See, there’s where talking about “Bash” gets you into trouble.

I’ve got something like 10 Linux boxes in this room here with me that don’t 
have Bash on them.  They run Busybox[1] instead; its “sh” implementation is 
based on the Almquist shell.[2]


[1] https://busybox.net/
[2] https://en.wikipedia.org/wiki/Almquist_shell

> For now, there are non-native emulators MinGW/MSys and Cygwin to provide
> Bash on Windows.

MSYS and Cygwin are neither non-native nor “emulators.”  Executables produced 
by the MSYS and Cygwin GCC compilers are, in fact, more “native” than WSL 
executables.

WSL runs Linux ELF executables and implements the Linux kernel syscall 
interface.  Cygwin runs Windows PE executables and implements a POSIX/Linux 
interface in terms of the native Windows API.  MSYS is the same, being a fork 
of Cygwin.

> Cygwin
> http://www.mingw.org/node/21

That’s a very one-sided argument.

Cygwin applications can call into the native Windows API.  It is bad form to do 
something via the native Windows API that Cygwin already provides, as there may 
be cross-app interop considerations when you bypass the POSIX API that Cygwin 
provides, but there is nothing actually stopping you from doing that.

In fact, one improvement made to SQLite a few years ago was to switch it from 
using native Windows file locking when built under Cygwin to use POSIX or BSD 
locking mechanisms, so that two programs built under Cygwin that both used 
SQLite would get the advisory locking semantics they expect, not the mandatory 
locking semantics Windows gives you by default.  (It’s more complicated than 
that, but I don’t want to go deeper into it here.)

Instead of letting the MinGW people tell you what Cygwin is, how about you let 
the Cygwin project speak for themselves:

   https://cygwin.com/cygwin-ug-net/programming.html
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Roman Fleysher]

I am not even sure myself this is the right path.

I have table with file names and need operations to be performed on columns  
(i.e. on files). Results, numeric or new file names,  are to be recorded in a 
column. I see two ways:

From bash script, make list of rows, run commands, load results to sqlite. Or

From sqlite, use extension to run commands for each row.

Both have issues.

Roman




 Original message 
From: Richard Hipp <d...@sqlite.org>
Date: 1/11/17 7:23 PM (GMT-05:00)
To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>
Subject: Re: [sqlite] extension to run bash

On 1/11/17, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote:
>
> For anyone thinking that it is a good idea to embed shell
> functionality in the SQL interpreter, it makes the SQL interpreter
> much less secure for untrusted inputs.

Nobody is suggesting that this become a standard feature of the
language.  Roman wants a "loadable extension", a separate shared
library that will only be used by Roman himself, and then under
carefully controlled circumstances.
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Richard Hipp]

On 1/11/17, Bob Friesenhahn  wrote:
>
> For anyone thinking that it is a good idea to embed shell
> functionality in the SQL interpreter, it makes the SQL interpreter
> much less secure for untrusted inputs.

Nobody is suggesting that this become a standard feature of the
language.  Roman wants a "loadable extension", a separate shared
library that will only be used by Roman himself, and then under
carefully controlled circumstances.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Bob Friesenhahn]

On Wed, 11 Jan 2017, Jim Callahan wrote:


How much doing all that is worth is a different question, since the calls

made through this

proposed system() SQLite function would also likely be non-portable.  In

this very example,

there is no wc on Windows.


I would suggest renaming the proposed system() function bash() since now
and in the future there may be different command line shells.


For anyone thinking that it is a good idea to embed shell 
functionality in the SQL interpreter, it makes the SQL interpreter 
much less secure for untrusted inputs.


There are already SQL injection exploit opportunities and now SQL 
injection exploit opportunities also become shell exploit 
opportunities.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Jim Callahan]

> How much doing all that is worth is a different question, since the calls
made through this
> proposed system() SQLite function would also likely be non-portable.  In
this very example,
> there is no wc on Windows.

I would suggest renaming the proposed system() function bash() since now
and in the future there may be different command line shells.

The (now) new Windows 10 Anniversary Edition has the option of installing a
shell that nearly runs Canonical Ubuntu Linux's BASH shell. In a few years
it will likely be a routine part of Windows.

See:
https://msdn.microsoft.com/en-us/commandline/wsl/about

Thus, at some point, Linux, OS/X and Windows will all support Bash scripts.

For now, there are non-native emulators MinGW/MSys and Cygwin to provide
Bash on Windows.

MinGW/MSys
http://www.mingw.org/wiki/msys

Cygwin
http://www.mingw.org/node/21

Jim Callahan
Orlando, FL



On Wed, Jan 11, 2017 at 5:21 PM, Warren Young  wrote:

> On Jan 11, 2017, at 3:11 PM, Richard Hipp  wrote:
> >
> > On 1/11/17, Scott Hess  wrote:
> >>  UPDATE result SET nRows = system('wc', '-l', fileNames);
> >>
> >> ...
> >> [Though, yes, this means you'll have to use fork() and execlp() and
> >> waitpid() to implement, rather than popen().
> >
> > Which further means that the code would not be portable to Windows.
>
> There is a way to do popen() in Windows, but it’s reeealy ugly:
>
>https://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx
>
> How much doing all that is worth is a different question, since the calls
> made through this proposed system() SQLite function would also likely be
> non-portable.  In this very example, there is no wc on Windows.
>
> This is essentially the same problem that leads to autoconf, autosetup,
> CMake, etc: you can’t write a portable Makefile, if by “portable” you
> include non-POSIX OSes.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Warren Young]

On Jan 11, 2017, at 3:11 PM, Richard Hipp  wrote:
> 
> On 1/11/17, Scott Hess  wrote:
>>  UPDATE result SET nRows = system('wc', '-l', fileNames);
>> 
>> ...
>> [Though, yes, this means you'll have to use fork() and execlp() and
>> waitpid() to implement, rather than popen().
> 
> Which further means that the code would not be portable to Windows.

There is a way to do popen() in Windows, but it’s reeealy ugly:

   https://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx

How much doing all that is worth is a different question, since the calls made 
through this proposed system() SQLite function would also likely be 
non-portable.  In this very example, there is no wc on Windows.

This is essentially the same problem that leads to autoconf, autosetup, CMake, 
etc: you can’t write a portable Makefile, if by “portable” you include 
non-POSIX OSes.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Richard Hipp]

On 1/11/17, Scott Hess <sh...@google.com> wrote:
> Though it may be cleaner long-term to implement system() to pass
> individual arguments, rather than passing a single string which will
> have to be re-processed by the shell.  So the API would end up like:
>   UPDATE result SET nRows = system('wc', '-l', fileNames);
>
> The reason I suggest this is because [fileNames] could have spaces
> which would have to be escaped, but there are probably a dozen other
> similar issues which are likely to come up.
>
> [Though, yes, this means you'll have to use fork() and execlp() and
> waitpid() to implement, rather than popen().

Which further means that the code would not be portable to Windows.

> There are examples out
> there of how to do that:
>
> https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132
> ]
>
> -scott
>
> On Wed, Jan 11, 2017 at 1:38 PM, Roman Fleysher
> <roman.fleys...@einstein.yu.edu> wrote:
>> Yes, Richard, this is exactly what I mean.
>>
>> Roman
>> 
>> From: sqlite-users [sqlite-users-boun...@mailinglists.sqlite.org] on
>> behalf of Richard Hipp [d...@sqlite.org]
>> Sent: Wednesday, January 11, 2017 4:34 PM
>> To: SQLite mailing list
>> Subject: Re: [sqlite] extension to run bash
>>
>> On 1/11/17, Roman Fleysher <roman.fleys...@einstein.yu.edu> wrote:
>>> Dear SQLites,
>>>
>>> I am using exclusively sqlite3 shell for all the processing and may need
>>> ability to run bash commands and assign result to a column. For example:
>>>
>>> UPDATE  result SET nRows =` wc -l fileNames` ;
>>>
>>> Here I used `` as would be in bash for command substitution. This would
>>> run
>>> wc command (word count), count number of lines in each file listed in
>>> column
>>> fileNames and update the row correspondingly.
>>>
>>> As far as I understand I should be able to write loadable extension to
>>> accomplish this.
>>
>> No, You cannot do exactly what you describe with a loadable extension.
>>
>> But you could, perhaps, create a loadable extension that implements a
>> new system() SQL function like this:
>>
>>UPDATE result SET nRows = system('wc -l ' || fileNames);
>>
>> Note that || is the SQL string concatenation operator.  You didn't
>> say, but I'm guessing that fileNames is a column in the result table.
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Scott Hess]

Though it may be cleaner long-term to implement system() to pass
individual arguments, rather than passing a single string which will
have to be re-processed by the shell.  So the API would end up like:
  UPDATE result SET nRows = system('wc', '-l', fileNames);

The reason I suggest this is because [fileNames] could have spaces
which would have to be escaped, but there are probably a dozen other
similar issues which are likely to come up.

[Though, yes, this means you'll have to use fork() and execlp() and
waitpid() to implement, rather than popen().  There are examples out
there of how to do that:
   
https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132
]

-scott

On Wed, Jan 11, 2017 at 1:38 PM, Roman Fleysher
<roman.fleys...@einstein.yu.edu> wrote:
> Yes, Richard, this is exactly what I mean.
>
> Roman
> 
> From: sqlite-users [sqlite-users-boun...@mailinglists.sqlite.org] on behalf 
> of Richard Hipp [d...@sqlite.org]
> Sent: Wednesday, January 11, 2017 4:34 PM
> To: SQLite mailing list
> Subject: Re: [sqlite] extension to run bash
>
> On 1/11/17, Roman Fleysher <roman.fleys...@einstein.yu.edu> wrote:
>> Dear SQLites,
>>
>> I am using exclusively sqlite3 shell for all the processing and may need
>> ability to run bash commands and assign result to a column. For example:
>>
>> UPDATE  result SET nRows =` wc -l fileNames` ;
>>
>> Here I used `` as would be in bash for command substitution. This would run
>> wc command (word count), count number of lines in each file listed in column
>> fileNames and update the row correspondingly.
>>
>> As far as I understand I should be able to write loadable extension to
>> accomplish this.
>
> No, You cannot do exactly what you describe with a loadable extension.
>
> But you could, perhaps, create a loadable extension that implements a
> new system() SQL function like this:
>
>UPDATE result SET nRows = system('wc -l ' || fileNames);
>
> Note that || is the SQL string concatenation operator.  You didn't
> say, but I'm guessing that fileNames is a column in the result table.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Roman Fleysher]

I know it is not magic. It is SQLite developers' brain and effort. But it looks 
like magic to me.

Yes, this is example I see how I could use.

I am still thinking if this is what I really need. I am working with images and 
need, among other things, some summary measures to be placed into tables for 
analysis.

Thank you,

Roman



From: sqlite-users [sqlite-users-boun...@mailinglists.sqlite.org] on behalf of 
Richard Hipp [d...@sqlite.org]
Sent: Wednesday, January 11, 2017 4:44 PM
To: SQLite mailing list
Subject: Re: [sqlite] extension to run bash

On 1/11/17, Roman Fleysher <roman.fleys...@einstein.yu.edu> wrote:
> Yes, Richard, this is exactly what I mean.
>

Then maybe use the https://www.sqlite.org/src/file/ext/misc/rot13.c
extension as a prototype from which to develop yours.

--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Richard Hipp]

On 1/11/17, Roman Fleysher  wrote:
> Yes, Richard, this is exactly what I mean.
>

Then maybe use the https://www.sqlite.org/src/file/ext/misc/rot13.c
extension as a prototype from which to develop yours.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Roman Fleysher]

Yes, Richard, this is exactly what I mean.

Roman

From: sqlite-users [sqlite-users-boun...@mailinglists.sqlite.org] on behalf of 
Richard Hipp [d...@sqlite.org]
Sent: Wednesday, January 11, 2017 4:34 PM
To: SQLite mailing list
Subject: Re: [sqlite] extension to run bash

On 1/11/17, Roman Fleysher <roman.fleys...@einstein.yu.edu> wrote:
> Dear SQLites,
>
> I am using exclusively sqlite3 shell for all the processing and may need
> ability to run bash commands and assign result to a column. For example:
>
> UPDATE  result SET nRows =` wc -l fileNames` ;
>
> Here I used `` as would be in bash for command substitution. This would run
> wc command (word count), count number of lines in each file listed in column
> fileNames and update the row correspondingly.
>
> As far as I understand I should be able to write loadable extension to
> accomplish this.

No, You cannot do exactly what you describe with a loadable extension.

But you could, perhaps, create a loadable extension that implements a
new system() SQL function like this:

   UPDATE result SET nRows = system('wc -l ' || fileNames);

Note that || is the SQL string concatenation operator.  You didn't
say, but I'm guessing that fileNames is a column in the result table.
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Jim Callahan]

> may need ability to run bash commands and assign result to a column. For
example:
​> ​
UPDATE  result SET nRows =` wc -l fileNames` ;

​Might be easier to run Bash commands in Bash; write the results to a file​
and then redirect the file into SQLite.

See for example, this Nabble thread.

http://sqlite.1065341.n5.nabble.com/How-accept-sqlite3-commands-from-stdin-td38710.html

Jim Callahan
Orlando, FL




On Wed, Jan 11, 2017 at 4:23 PM, Roman Fleysher <
roman.fleys...@einstein.yu.edu> wrote:

> Dear SQLites,
>
> I am using exclusively sqlite3 shell for all the processing and may need
> ability to run bash commands and assign result to a column. For example:
>
> UPDATE  result SET nRows =` wc -l fileNames` ;
>
> Here I used `` as would be in bash for command substitution. This would
> run wc command (word count), count number of lines in each file listed in
> column fileNames and update the row correspondingly.
>
> As far as I understand I should be able to write loadable extension to
> accomplish this. My questions are:
>
> 1. Given that I use sqlite3 shell exclusively, does this path makes sense?
> If path should be different, what is it?
> 2. If loadable extension is good way to go, is there an example that I
> could use given that I have zero knowledge of sqlite's internals?
>
> 3. Maybe mixing SQL and shell commands (different syntaxes) is
> linguistically inappropriate and thus difficult?
>
> Thank you,
>
> Roman
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] extension to run bash

[Richard Hipp]

On 1/11/17, Roman Fleysher  wrote:
> Dear SQLites,
>
> I am using exclusively sqlite3 shell for all the processing and may need
> ability to run bash commands and assign result to a column. For example:
>
> UPDATE  result SET nRows =` wc -l fileNames` ;
>
> Here I used `` as would be in bash for command substitution. This would run
> wc command (word count), count number of lines in each file listed in column
> fileNames and update the row correspondingly.
>
> As far as I understand I should be able to write loadable extension to
> accomplish this.

No, You cannot do exactly what you describe with a loadable extension.

But you could, perhaps, create a loadable extension that implements a
new system() SQL function like this:

   UPDATE result SET nRows = system('wc -l ' || fileNames);

Note that || is the SQL string concatenation operator.  You didn't
say, but I'm guessing that fileNames is a column in the result table.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] extension to run bash

[Roman Fleysher]

Dear SQLites,

I am using exclusively sqlite3 shell for all the processing and may need 
ability to run bash commands and assign result to a column. For example:

UPDATE  result SET nRows =` wc -l fileNames` ;

Here I used `` as would be in bash for command substitution. This would run wc 
command (word count), count number of lines in each file listed in column 
fileNames and update the row correspondingly.

As far as I understand I should be able to write loadable extension to 
accomplish this. My questions are:

1. Given that I use sqlite3 shell exclusively, does this path makes sense? If 
path should be different, what is it?
2. If loadable extension is good way to go, is there an example that I could 
use given that I have zero knowledge of sqlite's internals?

3. Maybe mixing SQL and shell commands (different syntaxes) is linguistically 
inappropriate and thus difficult?

Thank you,

Roman


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users