command line (was Thanks GNUCash)

Tue Jul 12 17:33:42 EDT 2005

Robert Heller <heller at deepsoft.com> writes:
> > Yes, a quick CLI to just add transactions would be nice (eg one gets
> > home from 'shopping' with a pile of receipts - it would be nice to
> > quickly enter these transactions without having to fire up the whole
> > GUI. CLI access for various 'common' queries (current balances,
> > projected minimum, etc.) would also be nice.

(CLI: Command Line Interface: terminals, shells, SSH, etc.
GUI Graphical User Interface: Gnome, Gtk, KDE etc.
RFE: Request For Enhancement - a wishlist bug
QSF: XML format designed for the query engine from GnuCash.)

OK, after a little discussion on -devel, I've got an idea that could solve an 
existing RFE and I'd like to check a few points with users before I get too 
involved:

1. Users' data files can get seriously large - loading the entire data file 
into a CLI could take as long as loading the file in an already open GUI, 
which defeats the main objective of the CLI - speed.

2. It can be hard, IMHO, in a CLI to check that the data is complete and 
accurate in relation to existing data. Errors that will jump out at you in a 
GUI can be much harder to spot in a terminal window.

3. It's rare, in my experience, to find a single package that has both GUI and 
CLI programs - these are usually installed separately. It may therefore be 
useful to not make the CLI package dependent on the GnuCash package but 
instead be able to install it on systems where GnuCash cannot be used - even 
remotely over SSH or other crazy ideas.

Partially as a result of these issues, I've gone for a *separate* utility 
program that I can develop as a CLI for GnuCash. The main points are:

1. It relies on import/export in GnuCash (G2) - if you want to view data in 
the CLI, it will need to be exported and if you want to enter data in the CLI 
it will need to be imported. Export is quick and painless - as simple as Save 
As....

2. Successive edits can be incremental - you could edit the same data many 
times and only have to import it once. It could load a previous file, add (or 
amend) transactions to the partial book and save it for later import.

3. I can extend this to run under ncurses and provide simple menus or Q&A data 
entry, it could use defaults of some kind.

4. We can have something that looks like xf86config, or something like debconf 
(although that could take longer) or ....

5. I ran short of inspiration on the name front. All I can think of is 
CashUtil. Any better ideas? (No special characters or spaces, this needs to 
be a usable package name and reasonably short - and not exist already on 
SourceForge: http://sourceforge.net/)

6. It can easily be the basis of data-mining / customised data handling / 
reporting as it is, at it's heart, a SQL-type query engine (supports SELECT 
and INSERT so far). It could solve a lot of issues with standard reports not 
being quite what a specific user requires. A Perl XML parser will be 
available separately for the output XML (QSF).

7. It would have all the advantages of the command line: pipes, redirection, 
aliases etc. - it could easily go into a bash script or similar.

8. There are notable problems with currencies and shares - the GnuCash support 
for these is not currently compatible with the query engine. The CLI program 
may not be able to support these at all - at least initially - meaning that 
all data handling will need to be single currency.

9. All non-currency / non-commodity GnuCash objects are already supported, 
including all the business features.

10. Nevertheless, there's limited financial logic in this program - you might 
be able to create data that is financially inconsistent - but GnuCash will 
deal with problems like that when merging the data back into it's own files. 
Import therefore requires user involvement. At any point prior to the final 
"commit", you will be able to abort the import without losing or altering 
either the original GnuCash data or the import data.

11. It's based on Pilot-QOF, my current CLI project.
http://pilot-qof.sourceforge.net/ - improvements in one will feed through to 
the other in most cases.

First tarball is now available - 

http://code.neil.williamsleesmill.me.uk/cashutil.tar.gz

http://www.linux.codehelp.co.uk/#cashutil

Doxygen output: http://code.neil.williamsleesmill.me.uk/cashutil/

Note: This is not a formal release and the tarball is not signed (it's 
currently auto-generated). Feel free to inspect the code but don't expect to 
use it yet. (manpage included).

It runs against the v.latest QOF CVS but it won't run against existing GnuCash 
CVS yet but this should be sorted out with my next commit - the changes are 
relatively minor.

Queries, bug reports, patches, technical problems and offers of help to:
http://lists.sourceforge.net/lists/listinfo/qof-devel
qof-devel at lists.sourceforge.net

General discussions and replies to the above ideas can stay here.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20050712/ea57402c/attachment-0004.bin