Thanks for the quick fix Jim! I verified the bug is now fixed in the git
repository.
-Tim
On Sun, Apr 24, 2011 at 2:22 PM, Jim Meyering wrote:
> Thanks again.
> Here's the fix I expect to use:
>
> From 79a476abb35a69f409e2848019c8ebc24cc687cf Mon Sep 17 00:00:00 2001
> From: Jim Meyering
> Da
Tags: notabug
Eric Kever writes:
> I've created a file 'foo', and used tail -f to follow the changes to that
> file.
> I then wrote 'test' to the file and saved it, and tail reported 'test',
> which is fine.
> I then deleted 'test' and saved the file, and tail reported 'tail: foo:
> file truncated', which is f
On 04/13/2010 02:16 PM, Eric Kever wrote:
> I've created a file 'foo', and used tail -f to follow the changes to
> that file.
> I then wrote 'test' to the file and saved it, and tail reported 'test',
> which is fine.
> I then deleted 'test' and saved the file, and tail reported 'tail: foo:
> file t
I've created a file 'foo', and used tail -f to follow the changes to
that file.
I then wrote 'test' to the file and saved it, and tail reported 'test',
which is fine.
I then deleted 'test' and saved the file, and tail reported 'tail: foo:
file truncated', which is fine.
I then wrote 'test' again
Marc Perkel wrote:
> Just noticed this having upgraded to Fedora 12. I use tail -F to
> follow a file that vanishes and is recreated once a minute. It works
> for some time but eventually tail quits and goes back to the command
> prompt. Just thought I'd let you know in case you changed something.
Just noticed this having upgraded to Fedora 12. I use tail -F to follow
a file that vanishes and is recreated once a minute. It works for some
time but eventually tail quits and goes back to the command prompt. Just
thought I'd let you know in case you changed something.
tail: `info.log' has b
Eric Blake wrote:
> $ echo abc | tail -c +1
> tail: cannot open `+1' for reading: No such file or directory
> $ echo abc | tail -c+1
> abc
> $ tail --version | head -n1
> tail (GNU coreutils) 7.6
>
> Shouldn't -c behave the same, whether or not there is a space before the
> count argument?
Thanks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
$ echo abc | tail -c +1
tail: cannot open `+1' for reading: No such file or directory
$ echo abc | tail -c+1
abc
$ tail --version | head -n1
tail (GNU coreutils) 7.6
Shouldn't -c behave the same, whether or not there is a space before the
count argume
"smc" <[EMAIL PROTECTED]> writes:
> Using the coreutils version for tail GNU version 5.0.90, I get an incorrect
> result in the number of
> lines requested. By example:
>
> tail -17 Test.File | wc -l
> 19
>
>I verified that "wc" is not the problem.
Thanks for your report. I can't repro
Using the coreutils version for tail GNU version 5.0.90, I get an incorrect result
in the number of
lines requested. By example:
tail -17 Test.File | wc -l
19
I verified that "wc" is not the problem.
Thanks,
Steve Cherelstein
[EMAIL PROTECTED]
11 matches
Mail list logo
