GNU bug report logs - #14012
[coreutils] Please add timestamps to the output of tail -f

Previous Next

Package: coreutils;

Reported by: Filipus Klutiero <chealer <at> gmail.com>

Date: Wed, 20 Mar 2013 22:24:01 UTC

Severity: wishlist

Found in version 8.13

To reply to this bug, email your comments to 14012 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#14012; Package coreutils. (Wed, 20 Mar 2013 22:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Filipus Klutiero <chealer <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Wed, 20 Mar 2013 22:24:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Filipus Klutiero <chealer <at> gmail.com>
To: submit <at> bugs.debian.org, bug-coreutils <at> gnu.org
Subject: [coreutils] Please add timestamps to the output of tail -f
Date: Wed, 20 Mar 2013 18:21:20 -0400
Package: coreutils
Version: 8.13
Severity: wishlist

tail --follow is useful to see what is being added to a file. However, 
if the monitored file is followed for a certain period, it doesn't 
indicate when the new content was added. It would be nice if tail 
allowed to prepend timestamps to the output, as MultiTail's -ts option does.

This is a little delicate to do. The timestamp could be prepended to 
each line, or only to each atomic addition to the file. Also, as we 
don't know when the existing lines were added, we can't give them an 
exact timestamp. MultiTail stamps them with the time of MultiTail's 
launch, but I find that a bit misleading. I would consider simply not 
stamping these.
In any case, as this alters the output, this should be optional.

Scanning the changelog suggests this has not been implemented as of 8.21.




Information forwarded to bug-coreutils <at> gnu.org:
bug#14012; Package coreutils. (Wed, 20 Mar 2013 22:53:02 GMT) Full text and rfc822 format available.

Message #8 received at 14012 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Filipus Klutiero <chealer <at> gmail.com>
Cc: 703565 <at> bugs.debian.org, 14012 <at> debbugs.gnu.org
Subject: Re: Bug#703565: [coreutils] Please add timestamps to the output of
	tail -f
Date: Wed, 20 Mar 2013 16:50:49 -0600
[Message part 1 (text/plain, inline)]
Filipus Klutiero wrote:
> tail --follow is useful to see what is being added to a file.
> However, if the monitored file is followed for a certain period, it
> doesn't indicate when the new content was added. It would be nice if
> tail allowed to prepend timestamps to the output, as MultiTail's -ts
> option does.

But, but, but... multitail already does this.

> This is a little delicate to do. The timestamp could be prepended to
> each line, or only to each atomic addition to the file. Also, as we
> don't know when the existing lines were added, we can't give them an
> exact timestamp. MultiTail stamps them with the time of MultiTail's
> launch, but I find that a bit misleading. I would consider simply
> not stamping these.

As you note there is no clean solution for those previously added
lines.  No matter what is done it cannot be correct.

> In any case, as this alters the output, this should be optional.
> 
> Scanning the changelog suggests this has not been implemented as of 8.21.

This is most easily done using normal tools already.  As you know the
philosophy is that programs should do one thing and then those should
work together to build more complex things.  For example here is one
way to do what you are asking.  And this is just one of many
possibilities.

  $ tail -f /var/log/syslog | perl -MPOSIX -lne 'print strftime("%T ",localtime()), $_;'

Also there already exists multitail which does what you are asking.
If so then why not simply use multitail?  Is the natural progression
that tail be mutated into multitail?  In that case we should simply
use multitail directly.  But that does have a size penalty.

  $ ll -h /usr/bin/tail /usr/bin/multitail
  -rwxr-xr-x 1 root root 264K Jan 23  2012 /usr/bin/multitail
  -rwxr-xr-x 1 root root  67K Nov 18 08:25 /usr/bin/tail

Bob
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#14012; Package coreutils. (Thu, 21 Mar 2013 01:37:01 GMT) Full text and rfc822 format available.

Message #11 received at 14012 <at> debbugs.gnu.org (full text, mbox):

From: Filipus Klutiero <chealer <at> gmail.com>
To: 14012 <at> debbugs.gnu.org
Subject: Re: Bug#703565: [coreutils] Please add timestamps to the output of
	tail -f
Date: Wed, 20 Mar 2013 21:34:14 -0400
Hi Bob,

On 2013-03-20 18:50, Bob Proulx wrote:
> Filipus Klutiero wrote:
>> tail --follow is useful to see what is being added to a file.
>> However, if the monitored file is followed for a certain period, it
>> doesn't indicate when the new content was added. It would be nice if
>> tail allowed to prepend timestamps to the output, as MultiTail's -ts
>> option does.
> But, but, but... multitail already does this.
>
>> This is a little delicate to do. The timestamp could be prepended to
>> each line, or only to each atomic addition to the file. Also, as we
>> don't know when the existing lines were added, we can't give them an
>> exact timestamp. MultiTail stamps them with the time of MultiTail's
>> launch, but I find that a bit misleading. I would consider simply
>> not stamping these.
> As you note there is no clean solution for those previously added
> lines.  No matter what is done it cannot be correct.

I didn't mean to say there is no *clean* way to do this. For me, as long 
as the program behaves according to its documentation, it's clean. The 
documentation should simply explain the drawbacks.
If it's too difficult to choose one true behavior, options can be 
introduced to control the output for existing content and for new 
content. However, at this stage I suggest we simply figure out the best 
defaults, implement that... then see if we have more insatisfaction.
But, no, there is no *easy* solution. Given that any behavior is 
inconvenient, I certainly recommend to make this optional (i.e. 
non-default).
>
>> In any case, as this alters the output, this should be optional.
>>
>> Scanning the changelog suggests this has not been implemented as of 8.21.
> This is most easily done using normal tools already.  As you know the
> philosophy is that programs should do one thing and then those should
> work together to build more complex things.  For example here is one
> way to do what you are asking.  And this is just one of many
> possibilities.
>
>    $ tail -f /var/log/syslog | perl -MPOSIX -lne 'print strftime("%T ",localtime()), $_;'
>
> Also there already exists multitail which does what you are asking.
> If so then why not simply use multitail?  Is the natural progression
> that tail be mutated into multitail?  In that case we should simply
> use multitail directly.  But that does have a size penalty.
>
>    $ ll -h /usr/bin/tail /usr/bin/multitail
>    -rwxr-xr-x 1 root root 264K Jan 23  2012 /usr/bin/multitail
>    -rwxr-xr-x 1 root root  67K Nov 18 08:25 /usr/bin/tail
>
> Bob

I cannot answer these questions, as I do not know MultiTail. I'm not 
really saying MultiTail is a problem for me at this time. If you had 
asked me a couple of days ago though, I'd have had to answer I didn't 
know MultiTail. To find out about it, I had to read tail's Wikipedia 
page (and then, I tried 3 or 4 tail alternatives to find one with 
timestamped monitoring).
I suggested this because I have to use MultiTail when I could use tail 
to do my job exactly as well if only it had had this option. And, I 
suppose it's not only me needing this. For example, see this thread: 
http://stackoverflow.com/questions/21564/is-there-a-unix-utility-to-prepend-timestamps-to-lines-of-text
I understand this is a request to add a feature - the addition will 
surely complexify tail and make it heavier, as you say. Although I 
wouldn't think the binary would weight much more, I can see that any 
growth of coreutils is a concern when considering embedded devices. If 
your stance is that this feature would be worth it theoretically, but is 
not worth its weight at this point, I'd suggest to have the 
documentation point to MultiTail. On my side, I might suggest including 
MultiTail in standard Debian. If we think this feature is just 
uninteresting because it's too easy to code, then I'd suggest including 
an example full command to timestamp output in the documentation, for 
those of us who didn't touch perl since school days.

Thanks for the suggestions of alternatives. FWIW, the thread above had a 
simpler suggestion, $ tail -f foo| ts; However, ts is in moreutils, 
which isn't installed by default (in Debian), so it is no better than 
MultiTail in so far as an extra package must generally be installed.




Information forwarded to bug-coreutils <at> gnu.org:
bug#14012; Package coreutils. (Mon, 01 Apr 2013 17:40:01 GMT) Full text and rfc822 format available.

Message #14 received at 14012 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Filipus Klutiero <chealer <at> gmail.com>
Cc: 14012 <at> debbugs.gnu.org
Subject: Re: bug#14012: Bug#703565: [coreutils] Please add timestamps to the
	output of tail -f
Date: Mon, 1 Apr 2013 11:36:28 -0600
Additionally I ran into "annotate-output" today.

  NAME
       annotate-output - annotate program output with time and stream

  DESCRIPTION
       annotate-output  will  execute  the specified program, while prepending
       every line with the current time and O for stdout and E for
       stderr.

  EXAMPLE
       $ annotate-output make
       21:41:21 I: Started make
       21:41:21 O: gcc -Wall program.c
       21:43:18 E: program.c: Couldn't compile, and took me ages to find out
       21:43:19 E: collect2: ld returned 1 exit status
       21:43:19 E: make: *** [all] Error 1
       21:43:19 I: Finished with exitcode 2

Since you mentioned Debian I will note that it is packaged for Debian
in the devscripts packaged.  It seems to be an enhanced version of:

  http://jeroen.a-eskwadraat.nl/sw/annotate

Bob




This bug report was last modified 10 years and 364 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.