Following

If the standard input stream is a pipe (FIFO), it is not followed. Block devices and directories aren't followed ever.

Regular files that got truncated are output again in their entirety.

-F is most useful in log-rotation-style scenarios, where a file, such as, traditionally, /var/log/messages, is moved away (to /var/log/messages-20230703), and an empty file made in its place to hold new messages for the day. -f would continue to fruitlessly read the original file; -F detects this scenario (since /v/l/m is now a different file) and follows the new file named by the path, copying it from the beginning.

Without -r:

-n, --lines= lines

Copy the last lines of each file. Default: 10.

-c, --bytes= bytes

Copy the last bytes of each file.

-n, --lines=-lines

The same.

-c, --bytes=-bytes

The same.

-n, --lines=+lines

Start copying from the linesth line of each file.

-c, --bytes=+bytes

Start copying from the bytesth byte of each file.

With -r:

-r

Copy each file in reverse line order (last line first, then the previous).

-n, --lines= lines

Limit to lines.

-c, --bytes= bytes

Limit to bytes. Truncated lines have their starts removed.

Generally:

-z, --zero-terminated

Line separator is NUL, not newline. File headers are still written with newlines.

-q, --quiet, --silent

Never write file headers.

-v, --verbose

Always write file headers.

-f, --follow, --follow=descriptor

After files run out, keep trying to read them, and copy new data as it appears.

--follow=name

The same, but if they haven't seen new data in $\max ·\mathrm{interval}$ , check to see if they were replaced by a different file at the same location; if so: output that file in its entirety and follow it going forward.

-F

--follow=name --retry

--retry

With -f|-F: if a file wasn't found, skip it, process all the other files, then open and follow it when it appears while following.
Without: keep trying to open it synchronously (holding up other files) until it is.

--pid=pid

Exit 0 instantly when pid dies when following.

-s, --sleep=interval

If pid was specified, or any file cannot be poll(2)ed, polled, sleep for sleep(1)-style interval between checking. Default: 1s.

--max-unchanged-stats=max

With -F, try reopening file every maxth time it returns empty (or if it hasn't been readable in max iterations). No effect otherwise.

--follow values are prefix-matched (--follow=n is equivalent to --follow=name, &c.).

inotify

Consider the scenario where echo 'Rejtan je żur.' > f; tail -f f, then at some point in the future { sleep 0.5; echo 'Żupan go uciska.'; } > f — depending on how the sleep is clocked to interval, tail will either see the file become empty, detect the truncation, then see it grow "Żupan…", or it'll see the file having grown by two bytes (the dot and newline).

Truncation notwithstanding, either responsiveness or system load has to be sacrificed to detect updates to regular files and pipes at closer-to-real-time rate. Similarly, replacement detexion with -F suffers greatly from being quantised, effectively being saddled with an up-to-five-second delay by default.

Under Linux, inotify(7) is used by default to watch unpollable files, which means tail wins the truncation race the vast majority of the time (cf. BUGS). However, for the -F renaming case, this is less rosy: it works in the base-line log rotation case, but will fail to recognise, for example, mv /var /жар. This is deemed acceptable — against the pain of the unaccelerated behaviour — for the usual case; however, to achieve "just watch files, no odd quirks" behaviour, specify ---disable-inotify. (In this case, doing mv /var/log /var/лог or removing /var/log will disable acceleration automatically.)

If inotify(7) is available, not disabled, and hasn't failed, interval and max are effectively meaningless, since tail only wakes up when there's data to service.

Research UNIX

Appears in the Programmer's Workbench (PWB/UNIX) as tail(I) ("deliver the last part of a file") with a SYNOPSIS of

The BUGS note that

Version 7 AT&T UNIX sees

usage: tail +n[lbcr] [file]

 *	Type 'r' means in lines in reverse order from end
 *	 (for -r, default is entire buffer )

System V

CB-UNIX 2.1 carries a derivative of Programmer's Workbench (PWB/UNIX) tail with a SYNOPSIS of

f is in principle like modern-day -f: unless the input was a pipe, instead of exiting tail enters an infinite loop of sleeping for 1 second and copying the input file to the standard output stream until end-of-file.

CB-UNIX was, among others, the basis for AT&T System III UNIX, where it first saw light outside of AT&T. However, AT&T System III UNIX was the first one with named pipes (fifo(7)s), so the "is input a pipe" flag is once again misconstrued.

AT&T System V Release 1 UNIX changes the b units from 512 to <sys/param.h> BSIZE, dependent on the system's filesystem configuration (512 or 1024).

AT&T System V Release 3 UNIX rolls this back by explicitly defining

#define BSHIFT	9	/* log2(512)=9, 512 is standard buffer size */

AT&T System V Release 4 UNIX patches in 4.3BSD's r and number parsing (but not b) via SunOS.

The BSD

3BSD carries Programmer's Workbench (PWB/UNIX) tail (notably in contrast to being otherwise Version 7 AT&T UNIX).

4.0BSD sees a SYNOPSIS of

4.2BSD fixes the check for the input being a pipe to run after opening file and differentiates number being 0 from being not given.

4.3BSD expands the --mode buffer to 32kB and turns ±b from meaning 10·512 to 1·512 bytes.

4.3BSD-Tahoe exits if a write fails during f.

Standards

System V Interface Definition (“SVID”), and X/Open Portability Guide Issue 2 (“XPG2”) include Version 2 AT&T UNIX's tail.

IEEE Std 1003.2 (“POSIX.2”)'s tail ("Copy the last part of a file") sees a Synopsis of

tail	[−f] [ −c number ||| −n number ] [file]
Obsolescent versions:
tail	−[number][c|||l][f] [file]
tail	+[number][c|||l][f] [file]

The Single UNIX Specification (“SUS”) carries IEEE Std 1003.2 (“POSIX.2”) tail with the addition of the b obsolescent unit, expectedly defined as ·512c.

IEEE Std 1003.1-2001 (“POSIX.1”) removes the obsolescent usage.

IEEE Std 1003.1-2008 (“POSIX.1”) allows + to be used as an option delimiter like - (i.e. +n 10 is equivalent to -n 10), implementations to interpret a file of "-" as the standard input stream, forbids numbers of +0.

IEEE Std 1003.1-2024 (“POSIX.1”) adds -r, as present-day.

The BSD (again)

4.4BSD includes a new tail, with a SYNOPSIS of

The manual says that "The -f option is ignored if the standard input is a pipe, but not if it is a FIFO."; this is false, since this is triggered by lseek(2) on the standard input stream (i.e. if no files were given) returning ESPIPE. This stems from linguistic confusion over the standard distinguishing pipes and fifo(7)s which are, in fact, the same. -f is simply ignored if reading from the standard input stream and it is a pipe, as present-day.