[systemd-devel] [PATCH] journalctl: allow customizable output formats

[Daniel P. Berrange]

On Fri, Oct 03, 2014 at 02:13:51AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 22, 2014 at 04:33:28PM +0100, Daniel P. Berrange wrote:
> > The current '--output FORMAT' argument defines a number of
> > common output formats, but there are some useful cases it
> > does cover. In particular when reading application logs it
> > is often desirable to display the code file name, line number
> > and function name. Rather than defining yet more fixed output
> > formats, this patch introduces user defined output formats.
> Hi,
> 
> I think this makes sense. But I think that the format strings you
> propose are damn ugly :). Using %() for variables seems too heavy.
> Also, journal fields are all text, so I don't think that specifying
> the type is useful.

Well there are two virtual fields which are timestamps which the existing
hardcoded output modes convert into a date string in various ways. I want
the format strings we define here to be able to express the semantics of
the current hardcoded output modes, so this neccessitates a way to ask
for various date formats. 

Also although the physically stored journal fields are strings per the
journal API & storage backend, they can be simple string versions of
other data types. eg an application defined journal field could be used
to store an integer, floating point, boolean, etc. It would be natural
for the app to use many decimal places if storing a floating point value
in the journal, so being able to give data types in the output mode lets
us alter the precision displayed when extracting it again.  Of course my
patch didn't try todo this, it only deal with dates.
 
> Maybe we could adopt the {} format from Java and Python, as
> implemented in Python [1]. It has a fairly rich and consistent field
> formatting language. We would care only about the part relevant
> to strings, at least in the beginning.

I'll see what I can cook up along these lines, but the existing python
language is focused on C data types and doesn't directly provide types
for the various date formats to support, so we can't use it 100% as-is.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|