On Mon, 22.09.14 16:33, Daniel P. Berrange (berra...@redhat.com) 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. > > The format string is an arbitrary string which contains a > mixture of literal text and variable subsistitions. Each > variable name corresponds to a journal field name. A variable > name can be optionally followed by a data type, and in the > case of string types, a length limit.
Hmm, hmm, hmm. I am quite afraid about inventing a new template language for this. I can see the usecase though, and I sympasize with it. I am particularly afraid of the entire type thing. The fact that the journal is more or less typeless is after all by design: i really didn't want to invent a new type system. Adding this to the formatter now, kinda feels like adding it after all, but through the backdoor... So, I am not against this in general, but I'd really be careful with the language we define here, and try to make this as similar to an existing language (like the python/java one Zbigniew mentioned) as we can. Or even better, we already have a very limited formatting language in place, which is the "specifier" logic, that can replace %i, %f and such things in unit files, maybe we can build on this, and allow specifiers to take a field name as parameter. Then, if we really need formatters for different field "types", we could just give them high-level characters or so? Hmm, also, we already have a really bad formatter in place for the journal catalog files (which only replaces @foo@ by the value of field foo). We should probably use the same code for this new journalctl formatter and the catalog code. In fact the catalog formatter could really use some improvement... Maybe something like this: journalctl -O "%t %s{CODE_FILE}:%s{CODE_LINE} %d{_SOURCE_REALTIME_TIMESTAMP}" or something like that, where %t would simply map to the timestamp, and %s{} maps to a field name, and %d{} the same, but reformats the field as timestamp, assuming it is a UNIX timestamp formatted as number... Or something like that... Other ideas? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel