I think I'll do the following (as a joke, surprised no one did it already):
$ alias stalk='less +F'Stop using tail -f (mostly)
151–160 of 211 posts
Re: Stop using tail -f (mostly)
#152Re: Stop using tail -f (mostly)
#153Earlier quoted context omitted.
Is there a bug report open for that yet? FreeBSD has this so they should be able to resync easily enough
I don't think its a bug
If you want to be pedantic, no, it's not a bug but in the vast majority of the software world people use the term “bug tracker” to refer to a system which also tracks new work which isn't strictly a defect.
And, since we're being pedantic, when I said “vast majority of the software world”, that includes the OpenBSD project:
“Sending in bug reports
If possible, use the sendbug(1) command to get the bug into our tracking system. Sendbug requires that your system can properly send Internet email. If you cannot use sendbug on a functional OpenBSD machine, please send your bug report to bugs@openbsd.org.
Perhaps what you are sending in is a feature request, not necessarily a bug. New features are accepted, especially with code that implements your suggested new feature.”
Re: Stop using tail -f (mostly)
#154Interesting.
I always preferred
watch -n 1 -d 'tail /path/to/log/file'
because of its nice highlighting feature.
Re: Stop using tail -f (mostly)
#155Earlier quoted context omitted.
on OpenBSD -f does: Do not stop when end-of-file is reached, but rather to wait for additional data to be appended to the input. If the file is re- placed (i.e., the inode number changes), tail will reopen the file and continue. If the file is truncated, tail will reset its position to the beginning. This makes tail more useful for watching log files that may get rotated. The -f option is ig- nored if the standard in…
Is there a bug report open for that yet? FreeBSD has this so they should be able to resync easily enough
Why? OpenBSD's implementation makes sense to me.
> FreeBSD has this
OpenBSD ≠ FreeBSD, and that's fine.
Re: Stop using tail -f (mostly)
#156I've literally never had this problem and nothing is wrong with tail -f for me. Quitting tail to use grep on the file is anything but inconvenient for me.
Re: Stop using tail -f (mostly)
#157Earlier quoted context omitted.
I always thought it was such a shame that you couldn't use plain poll() for this. poll()-ing on a read fd at EOF for a regular file should work like poll()-ing a network socket.
The problem is in what concepts are being considered "the same" when mapping two mostly-dissimilar things (a socket or pipe, vs a file). poll(), select() et al don't define "readable" as meaning "a byte of data is available". They define it as "read() will not block". When you read to the end of a file, read() returns "". This is the same as when you try to read from a closed socket. Conceptually, they are linking th…
> poll(), select() et al don't define "readable" as meaning "a byte of data is available". They define it as "read() will not block".
If that were true, poll() wouldn't return read-ready on a file-based fd until the data was actually sitting in buffers. After all, that's the only way to guarantee it won't block. That would actually be a useful semantic.
But what actually happens is that poll() on a file-based fd is basically a no-op that always returns true immediately, AFAIK. Someone could pull the disk drive cable before you actually call read(), in which case read() will indeed block, forever.
The existing semantic is useless. What argument is there in favor of a useless semantic?
This semantic wouldn't solve the "tail -f" problem, but at least it would be useful: http://cr.yp.to/unix/asyncdisk.html
Re: Stop using tail -f (mostly)
#158Earlier quoted context omitted.
I don't think its a bug
If you want to be pedantic, no, it's not a bug but in the vast majority of the software world people use the term “bug tracker” to refer to a system which also tracks new work which isn't strictly a defect. And, since we're being pedantic, when I said “vast majority of the software world”, that includes the OpenBSD project: “Sending in bug reports If possible, use the sendbug(1) command to get the bug into our tracki…
Ok, but it has an -f behavior that seems to do the right thing. I don't think I would file a request to add flags that aren't needed.
I'm not being "pedantic", I just don't think there is anything to change.
Re: Stop using tail -f (mostly)
#159Re: Stop using tail -f (mostly)
#160Earlier quoted context omitted.
$ less +F +/mypattern^M /my/file/to/search_and_follow * Note that I needed to "quote" (^V^M) that carriage-return to get the search pattern to work. Happy searching-and-following.
Thanks! Any idea what the quoted carriage return does? I wouldn't have thought of that in a million years.
> Any idea what the quoted carriage return does?
From creating vi (nvi, on NetBSD) macros, I'm used to thinking in terms of competely replicating the keystrokes that one would do interactively... so I tried it both ways (with and without ^M). The way I published is the one that works. Why the ^M ? Because if you're working interactively the search-pattern isn't submitted until you press Enter. nvi(1) (what NetBSD (and Free and OpenBSD) uses) will accept "-c" "command" arguments which are similar to the less(1) "+"... so, you can:
$ vi -c 123 ./myfile
and start editing "./myfile" at line 123. Nice for edit/compile/edit/compile dance that might happen if you're developing software. Play with that (and try your imagination with other ideas).
Have fun, happy exploring.