GNU bug report logs -
#32198
tail -f -F unexpected behavior
Previous Next
Reported by: Matthew Guidry <mguid2088 <at> gmail.com>
Date: Wed, 18 Jul 2018 15:21:02 UTC
Severity: normal
Tags: notabug
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32198 in the body.
You can then email your comments to 32198 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#32198
; Package
coreutils
.
(Wed, 18 Jul 2018 15:21:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Matthew Guidry <mguid2088 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Wed, 18 Jul 2018 15:21:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This is for tail v8.28 encountered on Ubuntu 18.04.
I was doing some experimentation with nano v2.9.3 and tail,
watching the output of tail after saving in nano and encountered some
strange behavior.
I had two terminals open side by side; one with nano and one with tail.
I opened a file called test.txt in nano and saved with ^w in the first
terminal.
I went to the second terminal and ran tail -f test.txt to watch the file.
I went back to the nano terminal and returned twice and saved.
The tail terminal reports this change properly.
With the file still open in nano, I write any number of characters and save.
The tail terminal reports this change But skips the first character. I also
tested this with -F.
This may not be an issue because it only happens when using the
write(ctrl-o, ctrl-s) in nano and not closing the file.
I have reproduced this on two machines.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#32198
; Package
coreutils
.
(Fri, 18 Jan 2019 21:35:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 32198 <at> debbugs.gnu.org (full text, mbox):
tags 32198 notabug
close 32198
stop
Hello,
It seems your message has not been replied to in a long while.
Sorry about that.
On 2018-07-18 8:24 a.m., Matthew Guidry wrote:
> I was doing some experimentation with nano v2.9.3 and tail,
> watching the output of tail after saving in nano and encountered some
> strange behavior.
This is not a bug at all (not in tail nor in nano).
It is the result of updating a file in-place (i.e. changing existing
bytes) which 'tail' already consumed.
> I had two terminals open side by side; one with nano and one with tail.
> I opened a file called test.txt in nano and saved with ^w in the first
> terminal.
> I went to the second terminal and ran tail -f test.txt to watch the file.
>
> I went back to the nano terminal and returned twice and saved.
> The tail terminal reports this change properly.
> With the file still open in nano, I write any number of characters and save.
>
> The tail terminal reports this change But skips the first character.
To better see what happens, open a third terminal,
and run the following command (after initially saving the file):
watch -n1 od -tc test.txt
Which will show the content of the file, updated once a second.
I will use a similar but slightly different flow:
1. When you first save (in nano) the file, it is empty.
The "od" terminal will show:
0000000
2. Type "12345" (don't press ENTER), and save (ctrl-O).
The "od" terminal will show:
0000000 1 2 3 4 5 \n
0000006
The "tail" terminal will show:
12345
AND the cursor in the "tail" terminal will go to the next line
(as there is a newline in the file).
3. Still in nano, on the same line, type "67890" (don't press ENTER),
and save (CTRL-O).
The "od" terminal will show:
0000000 1 2 3 4 5 6 7 8 9 0 \n
0000011
The "tail" terminal will show:
12345
7890
Here, the "6" character was not displayed by "tail".
The reason is that that character in offset 6 of the file used to be a
newline, and "tail" already consumed it.
When the line was changed, nano went back and changed existing data in
the file (or re-wrote the file completely - not sure about the
implementation). "tail" has no way to detect that or "go back" in the file.
This is a carefully constructed example, where the data change is
small enough so that that "tail" almost doesn't notice it.
If you make larger changes, or delete some parts of the file,
nano will rewrite the file completely and "tail" will issue a warning
such as:
tail: test.txt: file truncated
and then re-read the file.
As such I'm closing this as "not a bug", but discussion can continue
by replying to this thread.
regards,
- assaf
Added tag(s) notabug.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 18 Jan 2019 21:35:03 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
32198 <at> debbugs.gnu.org and Matthew Guidry <mguid2088 <at> gmail.com>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 18 Jan 2019 21:35:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 16 Feb 2019 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 150 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.