Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
So, now we have -o short, -o short-monotonic, and --iso-dates.
I'm sure we'll add a relative timestamp mode like the excellent one in
dmesg --human output in recent util-linux. So I'd say that it makes
sense to deprecate short-monotonic and add a new switch --timestamps,
--timestamps=monotonic → old short-monotonic
--timestamps=iso-date → what you're proposing
--timestamps=...
This makes the whole thing easier to grok, imo. Journalctl already has
1½ page listing of options...
The output options of journalctl have bugged me for some time now. There
are many options, but the usefulness of many of those is questionable.
At the same time, the choice of output modes lacks flexibility - this is
certainly not the last time that someone will come up with a new way to
format output and submit a patch for it to journalctl.
In my opinion, journalctl (and the journal API) should get an output
option that accepts a printf-like format string. With such a format
string, we would finally get all the flexibility with a simple and
well-understood syntax.
In addition to the standard journal fields, format strings could
reference non-standard fields using a syntax similar to udev's
'%env{FOOBAR}'. We could be able limit the length of the output similar
to what is done in printf. We could have (to get back on topic)
different format modifiers for different date formats (ISO,
human-readable, epoch, ...).
Just my 2 cents.
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
On Thu, 18.07.13 10:45, Thomas Bächler (tho...@archlinux.org) wrote:
Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
So, now we have -o short, -o short-monotonic, and --iso-dates.
I'm sure we'll add a relative timestamp mode like the excellent one in
dmesg --human output in recent util-linux. So I'd say that it makes
sense to deprecate short-monotonic and add a new switch --timestamps,
--timestamps=monotonic → old short-monotonic
--timestamps=iso-date → what you're proposing
--timestamps=...
This makes the whole thing easier to grok, imo. Journalctl already has
1½ page listing of options...
The output options of journalctl have bugged me for some time now. There
are many options, but the usefulness of many of those is questionable.
At the same time, the choice of output modes lacks flexibility - this is
certainly not the last time that someone will come up with a new way to
format output and submit a patch for it to journalctl.
In my opinion, journalctl (and the journal API) should get an output
option that accepts a printf-like format string. With such a format
string, we would finally get all the flexibility with a simple and
well-understood syntax.
In addition to the standard journal fields, format strings could
reference non-standard fields using a syntax similar to udev's
'%env{FOOBAR}'. We could be able limit the length of the output similar
to what is done in printf. We could have (to get back on topic)
different format modifiers for different date formats (ISO,
human-readable, epoch, ...).
Just my 2 cents.
Note that most of the existing output modes can actually not be replaced
by such a format string. For example the json mode will serialize a
variable number of paramters into a single line, which is hard to
express in format strings. So, having the current output modes in place is
certainly going to be necessary always.
That said, I'd be open for a patch that adds support for printing logs
via such a format string, as an alternative to the defined output
modes. As syntax I'd prefer if we could requse the % specifier syntax
for the special fields (we already use % specifiers in the unit files,
so this would just reuse this language here), and @FOOBAR@ for the
journal fields (this syntax is already used by the message catalog
stuff, for the same purpose).
I hope that makes sense?
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
On Thu, Jul 18, 2013 at 06:55:47PM +0200, Lennart Poettering wrote:
On Thu, 18.07.13 10:45, Thomas Bächler (tho...@archlinux.org) wrote:
Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
So, now we have -o short, -o short-monotonic, and --iso-dates.
I'm sure we'll add a relative timestamp mode like the excellent one in
dmesg --human output in recent util-linux. So I'd say that it makes
sense to deprecate short-monotonic and add a new switch --timestamps,
--timestamps=monotonic → old short-monotonic
--timestamps=iso-date → what you're proposing
--timestamps=...
This makes the whole thing easier to grok, imo. Journalctl already has
1½ page listing of options...
The output options of journalctl have bugged me for some time now. There
are many options, but the usefulness of many of those is questionable.
At the same time, the choice of output modes lacks flexibility - this is
certainly not the last time that someone will come up with a new way to
format output and submit a patch for it to journalctl.
In my opinion, journalctl (and the journal API) should get an output
option that accepts a printf-like format string. With such a format
string, we would finally get all the flexibility with a simple and
well-understood syntax.
In addition to the standard journal fields, format strings could
reference non-standard fields using a syntax similar to udev's
'%env{FOOBAR}'. We could be able limit the length of the output similar
to what is done in printf. We could have (to get back on topic)
different format modifiers for different date formats (ISO,
human-readable, epoch, ...).
Just my 2 cents.
Note that most of the existing output modes can actually not be replaced
by such a format string. For example the json mode will serialize a
variable number of paramters into a single line, which is hard to
express in format strings. So, having the current output modes in place is
certainly going to be necessary always.
That said, I'd be open for a patch that adds support for printing logs
via such a format string, as an alternative to the defined output
modes. As syntax I'd prefer if we could requse the % specifier syntax
for the special fields (we already use % specifiers in the unit files,
so this would just reuse this language here), and @FOOBAR@ for the
journal fields (this syntax is already used by the message catalog
stuff, for the same purpose).
Just a note: git log pretty format is used for something similar, and
it would be great to follow the lessons learned there. For example,
it is necessary to be able place some fields on a line of their own,
iff the field exists, and put nothing otherwise, and also that it's
nicer to have terminator not separator semantics.
Zbyszek
--
they are not broken. they are refucktored
-- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
On Wed, 17.07.13 17:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: +/para/listitem +/varlistentry So, now we have -o short, -o short-monotonic, and --iso-dates. I'm sure we'll add a relative timestamp mode like the excellent one in dmesg --human output in recent util-linux. So I'd say that it makes sense to deprecate short-monotonic and add a new switch --timestamps, --timestamps=monotonic → old short-monotonic --timestamps=iso-date → what you're proposing --timestamps=... This makes the whole thing easier to grok, imo. Journalctl already has 1½ page listing of options... I agree with Zbigniew here. Having this feature sounds useful, but please not in a new switch of its own. However I am not convinced that a --timestamps= switch would be necessary for this either, because I figure that the only --output= mode where iso dates would be useful would be short. It's not useful for the json, json-pretty, json-sse, export, or cat modes, and only semi-useful for verbose mode. It's primarily useful for the short mode. Given that we already have a short-monotonic mode, maybe we should just add more like these? i.e. --output=short-iso or so? If one day we really get multiple modes where ISO dates could be useful then maybe we could internally handles this by considering the --output= param no longer as single value but always as a pair separated by a dash or so. If you follow what I mean. So, yeah, I'd think adding this as --output=short-iso or so would be the nicest? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
On Thu, Jul 18, 2013 at 01:36:51AM +0200, Lennart Poettering wrote: On Wed, 17.07.13 17:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: +/para/listitem +/varlistentry So, now we have -o short, -o short-monotonic, and --iso-dates. I'm sure we'll add a relative timestamp mode like the excellent one in dmesg --human output in recent util-linux. So I'd say that it makes sense to deprecate short-monotonic and add a new switch --timestamps, --timestamps=monotonic → old short-monotonic --timestamps=iso-date → what you're proposing --timestamps=... This makes the whole thing easier to grok, imo. Journalctl already has 1½ page listing of options... I agree with Zbigniew here. Having this feature sounds useful, but please not in a new switch of its own. However I am not convinced that a --timestamps= switch would be necessary for this either, because I figure that the only --output= mode where iso dates would be useful would be short. It's not useful for the json, json-pretty, json-sse, export, or cat modes, and only semi-useful for verbose mode. It's primarily useful for the short mode. Given that we already have a short-monotonic mode, maybe we should just add more like these? i.e. --output=short-iso or so? If one day we really get multiple modes where ISO dates could be useful then maybe we could internally handles this by considering the --output= param no longer as single value but always as a pair separated by a dash or so. If you follow what I mean. So, yeah, I'd think adding this as --output=short-iso or so would be the nicest? Yep, that will work too, with less work. Zbyszek -- they are not broken. they are refucktored -- alxchk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
On Thu, Jul 18, 2013 at 01:36:51AM +0200, Lennart Poettering wrote: On Wed, 17.07.13 17:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: +/para/listitem +/varlistentry So, now we have -o short, -o short-monotonic, and --iso-dates. I'm sure we'll add a relative timestamp mode like the excellent one in dmesg --human output in recent util-linux. So I'd say that it makes sense to deprecate short-monotonic and add a new switch --timestamps, --timestamps=monotonic → old short-monotonic --timestamps=iso-date → what you're proposing --timestamps=... This makes the whole thing easier to grok, imo. Journalctl already has 1½ page listing of options... I agree with Zbigniew here. Having this feature sounds useful, but please not in a new switch of its own. However I am not convinced that a --timestamps= switch would be necessary for this either, because I figure that the only --output= mode where iso dates would be useful would be short. It's not useful for the json, json-pretty, json-sse, export, or cat modes, and only semi-useful for verbose mode. It's primarily useful for the short mode. Given that we already have a short-monotonic mode, maybe we should just add more like these? i.e. --output=short-iso or so? If one day we really get multiple modes where ISO dates could be useful then maybe we could internally handles this by considering the --output= param no longer as single value but always as a pair separated by a dash or so. If you follow what I mean. So, yeah, I'd think adding this as --output=short-iso or so would be the nicest? Additional --timestamp would be overkill, I think. New output mode works for me, I will rework the patch. -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
