Command-line in JavaScript

So I have a convenient little library-slash-utility kit (SQP - and I can't remember what it's supposed to stand for) that I use for private tools (my invoicing, my notes, household finances, that kind of thing); it consists of a wrapper for Perl's Term::Shell and includes convenience functions for arbitrary SQL, which it knows how to format nicely, and provides a useful framework for quick-and-dirty list and modification commands.

But it's still pretty clunky, and for a while now I've toyed with the idea of putting the CLI into JavaScript and fronting the whole thing from a local HTTP server, like Mojolicious.

Yesterday, I did just that, in about four hours. Turns out Mojolicious is very easy to wrap my head around, and it's been long past time to start hacking JavaScript, so ... all is well.

I hit a number of fascinating things while poking around looking for stuff:

• Here's how easy it is to slap together a bare-bones CLI in jQuery. Look at the demo! It's freaking cool!  And that's probably the best framework for my son's planned text-based adventure game.
• Naturally I also found things about JS from the command line, like this GlueScript: a Wx/JavaScript monstrosity that has me thinking hard (it looks pretty groovy; hack up your UI in a bundlable thing and attach an embedded Perl for CPAN-y things and man, you'd be cooking with gas!)
• Another jQuery terminal - lots of features.
• I ended up going with Termlib, and not only because its author is in Vienna while I sit in Budapest; it also has no jQuery dependency and it offers AJAX command handling out of the box without my thinking hard about it. So it was a natural choice.
• Somewhere along the line I ran across PPI, a Perl DOM parser ... um, the Perl DOM parser actually.

Anyway, turns out it was dead easy to capture stdout and route it back to the browser. Where I'd really like to go with this is something a little more elaborate, though - more "textured" objects and larger text snippets returned from scripts should be placed into a return, and there should be a log.

What really kicked all this off is IPython, because Peter Norvig used it to analyze XKCD's recent regexp meta-golf (now you have infinite problems, hee) - for the exact same reason I wanted to - to play actual regexp meta-golf. IPython lets you work along interactively with data structures and hit code against them, but in a way I personally don't like. I want little editors to pop up and still keep that history and be able to switch to a notebook editor while I'm still working.  All that jazz. And if I do that in Wx (say) it will take me another twenty years - but in the browser I can do it in a couple of weeks.

So I'm gonna.

SQP is going to be my quasi-REPL, except I hate REPLs. I want a rich REPL, so that's what I'm going to write.  But of course it will also default back down to the command line if you're not in browser mode. (That actually also exists, in e.g. Perl::Shell and Shell::Perl and surely many others.)  Well, we'll see what I actually end up doing. The basic idea is the same, though. I want an interactive environment kind of like Mathematica, where I can see things in a nicely formatted way, put things into files, build files using templates and literate programming techniques, make schematics and diagrams with live links to items - who knows? All that and more.

SQP

I factored something I ended up calling SQP out of the invoicing program.  It's a shell-based rapid SQL/Perl prototyping tool.  So far it's just got a quick way to find a database, use it for SQL, check the SQL for a couple of foot-shooting methods (forgetting 'where' clauses on delete and update), and add a command for each Perl script it finds in the directory.

It needs to be able to show/define/modify tables in some way, which it doesn't yet, and some other functionality is also still missing.  But it's a promising start.

Oh, and it still doesn't have any testing.  I mean, the whole thing is like fifty lines of code, but I'm sure there are plenty of ways I can fail when I change it next.

Other things to factor out:

• A Word template handler that's not the barely functional Decl monstrosity I'm using now, based on:
• A Word module that's a thin wrapper around the OLE object description, written in a declarative style using:
• A declarative OLE module wrapper definition language module.
• Some kind of ORM for the invoicing part, anyway.  Not sure how to manage it, exactly.  But I'd really like some kind of higher-level language for talking about SQL databases at the level of semantics (grouping tables into meaningful modules or something).  I'm sure somebody else is already doing something like this, so I'll also see if I can't research that.