On 2/16/21 7:43 PM, Grant Taylor via TUHS wrote:
> On 2/16/21 6:16 PM, Will Senn wrote:
>> Nice! Thanks Doug. Too bad, though... one gets ever tired of having 
>> to log into db's and a simple text db system would be useful. Even 
>> sqlite, which I love, requires login to get at information... I'm 
>> already logged in, why can't I just ask for my info and have it 
>> returned?
>
> What do you mean by "log into db's" in relation to SQLite?  I've never 
> needed to enter a username and password to access SQLite.
>
> If you /do/ mean username and password, I believe that some DBs will 
> allow you to authenticate using Kerberos.  Thus you should be able to 
> streamline DB access along with access to many other things.
>
> If you /don't/ mean username and password, then what do you mean? Are 
> you referring to needing to run a command to open and access the 
> SQLite DB?  Taking a quick gander at sqlite3 --help makes me think 
> that you can append the SQL(ite) command that you want to run to the 
> command line.
>
>
>
Oops. That's right, no username & password, but you still need to bring 
it up and interact with it... accept, as you say, you can enter your sql 
as an argument to the executable. OK, I suppose ... grump, grump... Not 
quite what I was thinking, but I'd be hard pressed to argue the 
difference between creating a handful of files in the filesystem (vs 
tables in sqlite) and then using some unix filter utilities to access 
and combine the file relations (vs passing sql to sqlite) other than, 
it'd be fun if there were select, col, row (grep?), join (inner, outer, 
natural), utils that worked with text without the need to worry about 
the finickiness of the database (don't stone me as a database 
unbeliever, I've used plenty in my day).

Will