since - display new lines from a text file
since [-L | -R lines | -S | -Z] [-c sep] [-dn] [-F db] targets
Since keeps a position in each target file ever presented to the pro-
gram, which is recorded in db. Each new execution of the program
recovers the last position visited in the file, seeks to that location
and copies new (appended) lines from that point to the present end of
The new end-of-file is recorded in the db file for the next execution
of since's benefit.
When the file changes inode or device, or gets smaller since assumes
all the lines are new, so it starts at the first line again.
If the target is a directory since outputs a list of the files in that
directory that have changed (with regard to st_ctime) since that direc-
tory was last viewed. See stat(2).
If the program is called as since then no options are forced.
Appends the character sep to each node name from each directory
since processes. Specify as '\000' to emulate -print0 output.
Delete the record for each of the targets from the db after the
The path to the time stamp meta file. The default is the base-
name of the program in the present user's home directory, pre-
fixed with a dot (.).
Print a brief help message.
List the status of each of the targets from the db. This
includes a comparison to the present file (if it exists) the
first column is either "no", "yes", or "new" for files which
have no additional data, some additional data, or are not listed
in the present db. Nonexistent files produce and error on
Don't update target's length in the meta file. In this case
since outputs starting from the same point in the target next
The number of lines to replay before previous position. Some
filters require some context to get started. When there are
fewer than lines lines in the file since outputs enough blank
lines to number the first new line as number lines+1. This
options is silently ignored when the target is a directory.
Set the current position for targets to the present end of file
before any lines are processed (aka. skip to the end).
Show only version information, as well as the default db name.
Replay each of the targets from the start (skip to zero).
Output the version of since and the default time-stamp path.
Display any new lines in /etc/motd.
since -Zn /etc/motd
A synonym for cat /etc/motd.
since -L /etc/motd
Compare the status of /etc/motd to the default db.
since -Ld /etc/motd >/dev/null
Remove the entry for /etc/motd from the db file. The redirec-
tion to /dev/null and the use of -L are the cheapest way to dis-
card any output.
xapply 'echo Start "%1"; since %1' *.log
With multiple targets specified it is very hard to tell where
one ends and the next begins: in this example we use xapply to
provide a "Start" line for each file.
xclate -T"since %x" -m xapply since *.log
Much the same effect with a little more xclate(1l) wrapper
Report the new files from the directory /var/tmp. Yes the redi-
rection is not a typing error.
Linux volume managers have a penchant for picking different device num-
bers for their volumes on reboot or remount. This breaks since's
database key for entries and replays the whole file. Either the
author(s) of LVM2 are missing the point of a device number, or I am.
Files which are removed from the filesystem leave lines in the since db
file, which may cause strange behavior when a new file with the same
device/inode/name combination is created. Applications should us a
private db file to avoid this issue, and truncate it at some obvious
point in the application flow.
The -S option can race with a very active file to produce some unex-
pected output. Redirect since's standard out to /dev/null to avoid
The format of the db file is not documented and should never be assumed
to be stable from version to version of since. It might be a good idea
to remove any db files after a major upgrade (i.e. the integer part of
the version number changes).
The db format may not work between NFS clients and servers (or peer NFS
clients) due to major device mappings being different. The major
device on the server will be a disk, while each client might pick a
different virtual one for the same mapped filesystem.
When since processes a target directory via an open file descriptor on
stdin and the specified db file's pathname is relative to the current
working directory the entry is read from the target rather than the
original cwd, as since has to fchdir(2) to the target to get a valid
opendir handle on it. (This happens in filesystem islands; which makes
this more of a feature than you'd think.) Use a full pathname for the
db file path to avoid this bug.
KS Braunsdorf, NonPlayer Character Guild
ksb swirl spam dot npcguild.org minus spam.
petef with no-Spam databits.net
sh(1), cat(1), tail(1), xapply(1l), Tee(1l), glob(1l), fchdir(2)