Gnucash reports from the CLI..

Allen S. Rout asr at ufl.edu
Wed May 29 11:02:14 EDT 2013


On 05/29/2013 10:14 AM, Derek Atkins wrote:
> "Allen S. Rout" <asr at ufl.edu> writes:

>> gnucash --run-customer-report="report-name"
>> --output-filename="/path/file.html"  --customer-id="000003"
> 
> This is an extremely report-specific command-line.  

You are correct; that was excruciatingly deliberate.  It might still
be excruciatingly wrong, though. :)


Here's the chain of logic:
  - Reports in gnucash are nuanced and highly varied in configuration
schema.
  - Gnucash currently has no command-line operational facilities.
  - A full-featured report configuration CLI is probably unworkable

I hadn't considered wrapping all the possible report options as you
suggested; I'm not sure how that changes my logic yet.

  - So; aim for absolute minimum of configuration input; only one
    fact.
  - Anyway, my itch is to output reports for my customers.
  - Let's see how much useful framework I can build within those
constraints.


>       --report-options="customer-id=000003"
> 
> But designing the interface to be generic is a lot of work.

Exactly; and validating, and all the rest of the chaff which is
supplied by the GUI configuration interface.  Of this I know
_nothing_.

"Build a complete report invocation CLI module" seems like too much
for a first contribution. ;) but I fantasize that "Invoke a report,
with one input" seems achievable.  It'd be worthwhile on its own;
there are several other requests for this particular feature.  And it
would illuminate in some detail the requirements for the more general
report CLI.


Taking a WAG at the design of the actual full report config design,
(innocent of code heretofore) I'd think we'd need a representation of
the necessary options prior to both the GUI config display and the CLI
interpretation.  That might require a structure as complex, in its
way, as generic options parsing infrastructure.  Ick.


> I'm not sure what you mean by "GNUspace".

Sorry; I think of tools like Emacs, specifically designed to be
extended by the userbase.  Mmm.  With Emacs in Guile coming up,
maybe that's the eventual extension engine. *koff*

> Just remember, however, that whatever gets implemented should be
> generic, not specific, because the next person is going to come
> along and suggest that they want a different report, or different
> options, or different settings that they want to set.

>From this I infer the opinion that the incremental goal of automating
access to a single report doesn't look like it'd scratch your itches.

Acknowledging that the generic case is the distal goal, would the
Gnucash collective entertain accepting patches aimed at limited report
CLI support as a waypoint?


- Allen S. Rout




More information about the gnucash-devel mailing list