Re: [sqlite] SQLite as a Shell Script

[Rowan Worth]

Ah, I stand corrected. Thanks for pointing that out!

Although if you try running a "db" script in an interactive shell:

bash 4.1.2 says: bash: /tmp/db: cannot execute binary file
zsh 4.3.10 says: zsh: /tmp/db: cannot execute binary file
dash 0.5.5.1 says: /tmp/db: /tmp/db: cannot execute binary file
tcsh 6.17.00 says: /tmp/db: /tmp/db: cannot execute binary file
busybox ash 1.15.1 says: /tmp/db: /tmp/db: cannot execute binary file

When explicitly pointed at the db (ie. "zsh /tmp/db"), bash was the only
one to complain. So in general it seems there's a difference between the
treatment of an executable-file-sans-shebang and
script-named-on-command-line.

-Rowan

On 17 November 2016 at 22:31, Wout Mertens <wout.mert...@gmail.com> wrote:

> actually, if a file is executable and missing a proper shebang, it is just
> interpreted by the shell. But getting that executable flag is indeed not
> trivial.
>
> On Wed, Nov 16, 2016 at 1:17 PM Rowan Worth <row...@dug.com> wrote:
>
> > Not true. You can go ahead and create a database called "ls", but:
> >
> > a) it will not be executable, and
> > b) the file will start with "SQLite format 3" rather than the requisite
> > "#!/bin/busybox ash"
> >
> > So the sysadmin would still have to manually execute the "script" with an
> > appropriate shell.
> > -Rowan
> >
> > On 16 November 2016 at 18:56, Wout Mertens <wout.mert...@gmail.com>
> wrote:
> >
> > > well, if you have a sysadmin that has "." in their path, you could
> write
> > a
> > > database called "ls" or common misspellings of commands, and that way
> > > execute arbitrary code if the sysadmin visits the system.
> > >
> > > Wout.
> > >
> > > On Wed, Nov 16, 2016 at 11:43 AM Rowan Worth <row...@dug.com> wrote:
> > >
> > > > Interesting but doesn't seem overly practical. If you're in a
> postiion
> > to
> > > > run 'busybox ash /foo/bar' then you can easily create a shell script
> > > > through simpler means.
> > > >
> > > > Filesystem access via ATTACH DATABASE is worth bringing attention to
> > > > though, as I think a lot of developers wouldn't expect that. It can
> be
> > > > mitigated via something like sqlite3_limit(db, SQLITE_LIMIT_ATTACHED,
> > 1)
> > > if
> > > > you don't need ATTACH functionality (maybe with a limit of zero?
> > haven't
> > > > tested it).
> > > >
> > > > Of course if you are paying proper attention to security you should
> > > already
> > > > be onto the SQL injection vectors that put ATTACH in user's hands
> > anyway
> > > :)
> > > >
> > > > -Rowan
> > > >
> > > > On 16 November 2016 at 07:10, jungle Boogie <jungleboog...@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > Pretty interesting article:
> > > > > https://www.invincealabs.com/blog/2016/11/sqlite-shell-script/
> > > > >
> > > > > This post documents how we were able to create a SQLite database
> that
> > > > > can be executed as an ash shell script purely from SQL queries.
> > > > >
> > > > >
> > > > > Found here:
> > > > >
> > > > https://www.reddit.com/r/netsec/comments/5cwb07/sqlite_
> > > as_a_shell_script/
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ---
> > > > > inum: 883510009027723
> > > > > sip: jungleboo...@sip2sip.info
> > > > > ___
> > > > > 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
> > >
> > ___
> > 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] SQLite as a Shell Script

[Wout Mertens]

actually, if a file is executable and missing a proper shebang, it is just
interpreted by the shell. But getting that executable flag is indeed not
trivial.

On Wed, Nov 16, 2016 at 1:17 PM Rowan Worth <row...@dug.com> wrote:

> Not true. You can go ahead and create a database called "ls", but:
>
> a) it will not be executable, and
> b) the file will start with "SQLite format 3" rather than the requisite
> "#!/bin/busybox ash"
>
> So the sysadmin would still have to manually execute the "script" with an
> appropriate shell.
> -Rowan
>
> On 16 November 2016 at 18:56, Wout Mertens <wout.mert...@gmail.com> wrote:
>
> > well, if you have a sysadmin that has "." in their path, you could write
> a
> > database called "ls" or common misspellings of commands, and that way
> > execute arbitrary code if the sysadmin visits the system.
> >
> > Wout.
> >
> > On Wed, Nov 16, 2016 at 11:43 AM Rowan Worth <row...@dug.com> wrote:
> >
> > > Interesting but doesn't seem overly practical. If you're in a postiion
> to
> > > run 'busybox ash /foo/bar' then you can easily create a shell script
> > > through simpler means.
> > >
> > > Filesystem access via ATTACH DATABASE is worth bringing attention to
> > > though, as I think a lot of developers wouldn't expect that. It can be
> > > mitigated via something like sqlite3_limit(db, SQLITE_LIMIT_ATTACHED,
> 1)
> > if
> > > you don't need ATTACH functionality (maybe with a limit of zero?
> haven't
> > > tested it).
> > >
> > > Of course if you are paying proper attention to security you should
> > already
> > > be onto the SQL injection vectors that put ATTACH in user's hands
> anyway
> > :)
> > >
> > > -Rowan
> > >
> > > On 16 November 2016 at 07:10, jungle Boogie <jungleboog...@gmail.com>
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > Pretty interesting article:
> > > > https://www.invincealabs.com/blog/2016/11/sqlite-shell-script/
> > > >
> > > > This post documents how we were able to create a SQLite database that
> > > > can be executed as an ash shell script purely from SQL queries.
> > > >
> > > >
> > > > Found here:
> > > >
> > > https://www.reddit.com/r/netsec/comments/5cwb07/sqlite_
> > as_a_shell_script/
> > > >
> > > >
> > > >
> > > > --
> > > > ---
> > > > inum: 883510009027723
> > > > sip: jungleboo...@sip2sip.info
> > > > ___
> > > > 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
> >
> ___
> 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] SQLite as a Shell Script

[Rowan Worth]

Not true. You can go ahead and create a database called "ls", but:

a) it will not be executable, and
b) the file will start with "SQLite format 3" rather than the requisite
"#!/bin/busybox ash"

So the sysadmin would still have to manually execute the "script" with an
appropriate shell.
-Rowan

On 16 November 2016 at 18:56, Wout Mertens <wout.mert...@gmail.com> wrote:

> well, if you have a sysadmin that has "." in their path, you could write a
> database called "ls" or common misspellings of commands, and that way
> execute arbitrary code if the sysadmin visits the system.
>
> Wout.
>
> On Wed, Nov 16, 2016 at 11:43 AM Rowan Worth <row...@dug.com> wrote:
>
> > Interesting but doesn't seem overly practical. If you're in a postiion to
> > run 'busybox ash /foo/bar' then you can easily create a shell script
> > through simpler means.
> >
> > Filesystem access via ATTACH DATABASE is worth bringing attention to
> > though, as I think a lot of developers wouldn't expect that. It can be
> > mitigated via something like sqlite3_limit(db, SQLITE_LIMIT_ATTACHED, 1)
> if
> > you don't need ATTACH functionality (maybe with a limit of zero? haven't
> > tested it).
> >
> > Of course if you are paying proper attention to security you should
> already
> > be onto the SQL injection vectors that put ATTACH in user's hands anyway
> :)
> >
> > -Rowan
> >
> > On 16 November 2016 at 07:10, jungle Boogie <jungleboog...@gmail.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > Pretty interesting article:
> > > https://www.invincealabs.com/blog/2016/11/sqlite-shell-script/
> > >
> > > This post documents how we were able to create a SQLite database that
> > > can be executed as an ash shell script purely from SQL queries.
> > >
> > >
> > > Found here:
> > >
> > https://www.reddit.com/r/netsec/comments/5cwb07/sqlite_
> as_a_shell_script/
> > >
> > >
> > >
> > > --
> > > ---
> > > inum: 883510009027723
> > > sip: jungleboo...@sip2sip.info
> > > ___
> > > 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
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite as a Shell Script

[Wout Mertens]

well, if you have a sysadmin that has "." in their path, you could write a
database called "ls" or common misspellings of commands, and that way
execute arbitrary code if the sysadmin visits the system.

Wout.

On Wed, Nov 16, 2016 at 11:43 AM Rowan Worth <row...@dug.com> wrote:

> Interesting but doesn't seem overly practical. If you're in a postiion to
> run 'busybox ash /foo/bar' then you can easily create a shell script
> through simpler means.
>
> Filesystem access via ATTACH DATABASE is worth bringing attention to
> though, as I think a lot of developers wouldn't expect that. It can be
> mitigated via something like sqlite3_limit(db, SQLITE_LIMIT_ATTACHED, 1) if
> you don't need ATTACH functionality (maybe with a limit of zero? haven't
> tested it).
>
> Of course if you are paying proper attention to security you should already
> be onto the SQL injection vectors that put ATTACH in user's hands anyway :)
>
> -Rowan
>
> On 16 November 2016 at 07:10, jungle Boogie <jungleboog...@gmail.com>
> wrote:
>
> > Hi All,
> >
> > Pretty interesting article:
> > https://www.invincealabs.com/blog/2016/11/sqlite-shell-script/
> >
> > This post documents how we were able to create a SQLite database that
> > can be executed as an ash shell script purely from SQL queries.
> >
> >
> > Found here:
> >
> https://www.reddit.com/r/netsec/comments/5cwb07/sqlite_as_a_shell_script/
> >
> >
> >
> > --
> > ---
> > inum: 883510009027723
> > sip: jungleboo...@sip2sip.info
> > ___
> > 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] SQLite as a Shell Script

[Rowan Worth]

Interesting but doesn't seem overly practical. If you're in a postiion to
run 'busybox ash /foo/bar' then you can easily create a shell script
through simpler means.

Filesystem access via ATTACH DATABASE is worth bringing attention to
though, as I think a lot of developers wouldn't expect that. It can be
mitigated via something like sqlite3_limit(db, SQLITE_LIMIT_ATTACHED, 1) if
you don't need ATTACH functionality (maybe with a limit of zero? haven't
tested it).

Of course if you are paying proper attention to security you should already
be onto the SQL injection vectors that put ATTACH in user's hands anyway :)

-Rowan

On 16 November 2016 at 07:10, jungle Boogie <jungleboog...@gmail.com> wrote:

> Hi All,
>
> Pretty interesting article:
> https://www.invincealabs.com/blog/2016/11/sqlite-shell-script/
>
> This post documents how we were able to create a SQLite database that
> can be executed as an ash shell script purely from SQL queries.
>
>
> Found here:
> https://www.reddit.com/r/netsec/comments/5cwb07/sqlite_as_a_shell_script/
>
>
>
> --
> ---
> inum: 883510009027723
> sip: jungleboo...@sip2sip.info
> ___
> 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] SQLite as a Shell Script

[jungle Boogie]

Hi All,

Pretty interesting article:
https://www.invincealabs.com/blog/2016/11/sqlite-shell-script/

This post documents how we were able to create a SQLite database that
can be executed as an ash shell script purely from SQL queries.


Found here:
https://www.reddit.com/r/netsec/comments/5cwb07/sqlite_as_a_shell_script/



-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite 3.14.2 autoconf (shell) doesn't build with SQLITE_OMIT_AUTHORIZATION, undefined reference

[Jose Arroyo]

Hello everyone,

I couldn't find this in the existing bug list so I decided to send this
email.

I downloaded the latest SQLite autoconf version from
https://www.sqlite.org/2016/sqlite-autoconf-3140200.tar.gz and tried
building it using this compile option, doing

CFLAGS="-DSQLITE_OMIT_AUTHORIZATION" ./configure ; make

Make failed, with the following error:

sqlite3-shell.o: In function `do_meta_command':
shell.c:(.text+0x6c91): undefined reference to `sqlite3_set_authorizer'
shell.c:(.text+0x6cb2): undefined reference to `sqlite3_set_authorizer'
collect2: error: ld returned 1 exit status
make: *** [sqlite3] Error 1

Which makes sense, because according to the SQLite doc if
SQLITE_OMIT_AUTHORIZATION is defined, then "The sqlite3_set_authorizer()
 API function is not
present in the library"

The following code was added  in shell.c (compared to version 3.12.2):
In do_meta_command:
...
  if( c=='a' && strncmp(azArg[0], "auth", n)==0 ){
if( nArg!=2 ){
  raw_printf(stderr, "Usage: .auth ON|OFF\n");
  rc = 1;
  goto meta_command_exit;
}
open_db(p, 0);
if( booleanValue(azArg[1]) ){
  sqlite3_set_authorizer(p->db, shellAuth, p);
}else{
  sqlite3_set_authorizer(p->db, 0, 0);
}
  }else
...
Which doesn't seem to be protected against SQLITE_OMIT_AUTHORIZATION being
defined.

Building directly with ./configure ; make   finished correctly.

If it makes I difference, I'm running Ubuntu 14.04, gcc 4.8.4, libtool
2.4.2 (hehe). The whole build output is the following:

z$ CFLAGS="-DSQLITE_OMIT_AUTHORIZATION" ./configure ;
make
[16-09-16 9:43]
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-unknown-linux-gnu file names to
x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain
format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... 

Re: [sqlite] SQLite Command Line Shell.

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/11/2010 10:28 PM, Kirk Clemons wrote:
> I would like to be able to tell SQLite that if line 2 is bad just skip to 
> line 3 and so on until the database has been parsed all the through 
> maximizing the amount of data I retain.

It would require detailed knowledge of the corruption and what it
affected.  For example a very slow brute force algorithm would be to ask
for all rows with a rowid >=0, add one to the highest returned and do
another select greater than that.  Perhaps repeat in reverse order.

You are however far better off preventing the corruption in the first
place, ensuring a good backup and recovery strategy etc.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxkaF0ACgkQmOOfHg372QRDWACcDUlXb5vpI00VvX5f0tbq548/
L4cAoMEbCws5s57qi+vj8Dz9sLKVc7H1
=FmQE
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite Command Line Shell.

[Kirk Clemons]

I am trying to alter the dump function of the command line shell. I am not 
completely familiar with C Programming so I am sort of in the dark here.
As I understand it's workings now the .dump command performs a 'select *' on 
each row in row id order. If it encounters an error it skips to the end of the 
database and takes each row in reverse order.
This means I get all the information before and after any errors.

This is great but ideally I would want any data in between as well. If I have a 
database with 100 rows and row 2 and 99 are corrupt
but everything in between is fine I lose my entire database when I call the 
dump command.

I would like to be able to tell SQLite that if line 2 is bad just skip to line 
3 and so on until the database has been parsed all the through maximizing the 
amount of data I retain.

Regards,
~Kirk.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite in a shell

[Joe Wilson]

The MSYS "start" command just circumvents the problem by starting a new clunky 
Windows cmd window.
The Cygwin, Emacs and remote users logging into a Windows box via telnet/ssh 
who prefer to work in
their native terminal program either have to hack the sqlite3 shell.c code to 
force an interactive
session, or use a cygwin-compiled sqlite3.exe.

--- Dennis Cote <[EMAIL PROTECTED]> wrote:
> You are correct. This is a common problem for Unix code under windows 
> (at least with MSYS), since isatty() doesn't work correctly. MSYS comes 
> with a start command to work around this issue. Instead of:
> 
> sqlite3 ...
> 
> you can use
> 
> start sqlite3 ...
> 
> at the MSYS prompt. It will start a windows command shell running 
> sqlite3 where the isatty returns the correct results, and hence the I/O 
> is flushed to the screen before any prompts for input.
> 
> HTH
> Dennis Cote
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [sqlite] sqlite in a shell

[Derrell . Lipman]

rahed <[EMAIL PROTECTED]> writes:

> Joe Wilson <[EMAIL PROTECTED]> writes:
>
>> I've seen this same behavior when running a MinGW-compiled sqlite3.exe in 
>> the cygwin shell. It has
>> something to do with the lack of flushing of information written to stdout 
>> (until close() anyway).
>> If you blindly type in the sqlite commands - it does work. Once you exit the 
>> shell via .q you can
>> see the entire output of the session.
>>
>> One workaround is to use a cygwin-compiled sqlite3.exe. Perhaps hacking the 
>> sqlite shell not to
>> buffer its console output would also do the trick.
>>
>
> I entered the commands (which I didn't do before) and I can see the
> output immediately. So the only hitch is a command line without a
> prompt sqlite>. 

The shell likely does not believe that it is running interactively for some
reason, and so is not presenting prompts.  Look at the documentation for the
shell to figure out how to tell it to go into interactive mode.

Derrell

Re: [sqlite] sqlite in a shell

[rahed]

Joe Wilson <[EMAIL PROTECTED]> writes:

> I've seen this same behavior when running a MinGW-compiled sqlite3.exe in the 
> cygwin shell. It has
> something to do with the lack of flushing of information written to stdout 
> (until close() anyway).
> If you blindly type in the sqlite commands - it does work. Once you exit the 
> shell via .q you can
> see the entire output of the session.
>
> One workaround is to use a cygwin-compiled sqlite3.exe. Perhaps hacking the 
> sqlite shell not to
> buffer its console output would also do the trick.
>

I entered the commands (which I didn't do before) and I can see the
output immediately. So the only hitch is a command line without a
prompt sqlite>. 

-- 
Radek

Re: [sqlite] sqlite in a shell

[Joe Wilson]

I've seen this same behavior when running a MinGW-compiled sqlite3.exe in the 
cygwin shell. It has
something to do with the lack of flushing of information written to stdout 
(until close() anyway).
If you blindly type in the sqlite commands - it does work. Once you exit the 
shell via .q you can
see the entire output of the session.

One workaround is to use a cygwin-compiled sqlite3.exe. Perhaps hacking the 
sqlite shell not to
buffer its console output would also do the trick.

--- rahed <[EMAIL PROTECTED]> wrote:

> I can run sqlite3 from a windows cmd but running it from msys shell or
> emacs shell doesn't work. No sqlite prompt and I have to interrupt the
> process with Ctrl c.
> 
> Does anyone know the cause?
> 
> Thank you.
> 
> -- 
> Radek
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[sqlite] sqlite in a shell

[rahed]

I can run sqlite3 from a windows cmd but running it from msys shell or
emacs shell doesn't work. No sqlite prompt and I have to interrupt the
process with Ctrl c.

Does anyone know the cause?

Thank you.

-- 
Radek