[nothrabannosir]

Even when you don't want less +F, a good alternative to tail -f is tail -F. It survives log rotation, and the file being temporarily inaccessible:

    --retry
	      keep trying to open a file even if it is inaccessible when  tail
	      starts  or if it becomes inaccessible later; useful when follow-
	      ing by name, i.e., with --follow=name

    -F        same as --follow=name --retry

[pimlottc]

+1 for -F. Note that --follow and --retry are gnuisms, while -F works on most implementations of tail (even though it's not part of POSIX).

[protomyth]

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 input is a pipe, but not if it is a FIFO.

So, no -F or --retry but a different default behavior

[acdha]

Is there a bug report open for that yet? FreeBSD has this so they should be able to resync easily enough

[rjcz]

Why would they? It's not needed - '-F', '--retry' and the like are redundant. IMVHO, OpenBSD's '-f' behaviour should have been the default elsewhere, too. How many times in the past have you deliberately followed the file descriptor (coreutils' default '-f' behaviour) instead of its name? Every single time I used it in the past on Linux, this is what I thought:

    "For f***** sake! I should have used '-F'! Arghhh...!"

Obviously, I'm paraphrasing ;^)

[acdha]

I'm not saying that the OpenBSD behaviour is wrong but that compatibility is a worthwhile goal. Adding a simple -F alias for their existing behaviour would allow people's habits & shell scripts to just work without changes.

[currysausage]

Why? OpenBSD's implementation makes sense to me.

> FreeBSD has this

OpenBSD ≠ FreeBSD, and that's fine.

[protomyth]

I don't think its a bug

[acdha]

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 [e-mail].

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.”

http://www.openbsd.org/report.html#bugtypes

[protomyth]

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.

[acdha]

The idea is that if everyone else is converging on "tail -F" supporting that as an alias means that people's habits & shell scripts just work without modification. That seems worth adding a single line to a switch statement to me.

[oofabz]

Me either, but bug reports are used for feature requests too, not only bugs.

[protomyth]

and I don't think it needs a new set of flags since it, for me, does the right thing with -f currently.

[varikin]

This is my standard now. Logs rotate all the time and it very convenient to have tail continue working without my intervention.

[fweespeech]

Yeah, tail -F is the way to go imo.

Also, if you are using a proper ssh client, opening a second ssh connection to manage the reacting to the log files is habit for me at this point. The only time I'm using tail -F is after a new configuration deployment. Otherwise, I'm looking at archival data in ELK.

[noddingham]

Have you tried using screen[1]? Might make things a little easier than have two separate SSH connections.

[1] https://www.gnu.org/software/screen/

[fweespeech]

Yes. I use it when I need to resume a SSH session. Given proper configuration, switching SSH tabs/connections is as easy as switching browser tabs...there is no real need for me to use screen for such a purpose.

Thank you for the suggestion tho. :)

[baq]

c.f. tmux