commit - 5270954a894e7fa33bdda2cf47a4d28ec61ba637
commit + f2865ef6ab291b7c23254068d3f6554985bbf6aa
blob - /dev/null
blob + 9fd016ae92cad3f1f7bcddc4d5401ddbc16525ea (mode 644)
--- /dev/null
+++ man/man1/snarfer.1
@@ -0,0 +1,48 @@
+.TH SNARFER 1
+.SH NAME
+snarfer \- manage the snarf buffer
+.SH SYNOPSIS
+.B snarfer
+[
+.B -v
+]
+.SH DESCRIPTION
+.I Snarfer
+watches the snarf buffer for changes.
+Each time a program changes the snarf buffer contents,
+.I snarfer
+copies the new contents and then takes over control
+of the buffer.
+Because the snarf buffer contents are managed by 
+.I snarfer
+instead of by individual programs, the contents remain
+available even after the program that wrote them exits.
+.PP
+The 
+.B -v
+option, intended for debugging, causes
+.I snarfer
+to print the new snarf buffer contents each time it changes.
+.PP
+On Mac OS X, 
+running
+.I snarfer
+keeps the X11 snarf buffer in sync with the Carbon snarf buffer,
+working around a bug in the OS X X11 server.
+See
+.IR getsnarf (3)
+for more details.
+.SH SOURCE
+.B \*9/src/cmd/snarfer.c
+.SH SEE ALSO
+Unix's \fIxclipboard\fR(1),
+.IR getsnarf (3)
+.SH BUGS
+Both
+.I xclipboard
+and
+.I snarfer
+want sole control of the snarf buffer.
+Running both at the same time will
+pass the snarf buffer back and forth between them
+in an infinite loop.