fsniper is a tool that monitors a given set of directories for new or modified files. Then, based on the file’s type or name, it invokes a script to be run on that file. Directories are monitored using inotify, instead of simply continuously polling them for changes. Common uses include making a single download directory for all things from a Web browser and having semi-intelligent scripts figure out what to do with those files. You write the scripts yourself.<\/p>\n
fsniper uses inotify to watch for when a file is closed after being written to. This means utilities such as touch will cause the event to trigger.<\/p>\n
fsniper can watch any number of directories for any number of pattern matches on the files.<\/p>\n
Download the sniper.tar.gz here<\/a> (may be old) <\/p>\n Example Configuration File<\/strong><\/p>\n Let’s jump into an example configuration file. ~\/tmp\/s { *.extension { \/.*regex.*\/ { *\/* { } In this configuration, we are watching only one dir, ~\/tmp\/s. Underneath that directory block, we are watching for 4 different patterns of files. The first pattern, image\/*, looks for files that match a mime-type pattern. Any image file will go into this block. The handler is echo, a standard system command that writes to stdout. fsniper looks for “%%” in the handler line. The name of the file that was just closed is substituted in for the %%. If no %% is found in the handler line, it appends it on the end.<\/p>\n The second pattern, *.extension, matches a shell glob for any file with the .extension extension. This pattern has two handlers. .\/foo1 is a custom script we write. If that script returns a return code that is not 0 or 2, it moves on to the next handler. See the Handler Return Codes section.<\/p>\n The third pattern, \/.regex.\/, matches the file name against a regular expression pattern. PCRE support must be compiled in for this pattern to work.<\/p>\n The fourth pattern, \/, matches any file (by mime-type wildcards). You could also use *, which would be a file glob.<\/p>\n Configuration<\/strong>: This section details all the available configuration options.<\/p>\n Matching Patterns<\/strong> – There are three types of patterns that fsniper can match against.<\/p>\n Mime-Types<\/strong> Shell Globs<\/strong> Regular Expressions<\/strong> Handlers<\/strong> Often, custom scripts are easier if they need to perform some complicated tests, or indicate that they will delay.<\/p>\n Handler Search Paths<\/strong> Handler Return Codes<\/strong> 2 : the handler will handle this event, but not right now. Retry again later.<\/p>\n other: this handler can not handle this file.<\/p>\n Delays<\/strong> There are two parameters that control delay handling. These parameters are placed in the configuration file on the top level, aka the same level as the watch block.<\/p>\n delay_time : the amount of time, in seconds, to wait before trying the handler again. If not specified, it defaults to 300, which is 5 minutes.<\/p>\n delay_repeats : the number of repeats it should try before giving up. This can be 0, meaning infinite retries.<\/p>\n fsniper Files<\/strong><\/p>\n By default, fsniper tries to load its configuration from ~\/.config\/sniper\/config. You can override this by specifying a configuration file on the command line.<\/p>\n fsniper keeps a log file in ~\/.config\/sniper\/log. You can use tail -f to monitor fsniper’s output.<\/p>\n Command Line Options<\/strong>
\nLatest version of fsniper-1.3.1.tar.gz<\/a><\/p>\n
\n
\nwatch {<\/p>\n
\n image\/* {
\n handler = echo
\n }<\/p>\n
\n handler = .\/foo1 a %% b
\n handler = mv %% arc-%%.txt
\n }<\/p>\n
\n handler = .\/foo2 a %% b
\n }<\/p>\n
\n handler = echo 2
\n }
\n }<\/p>\n
\n<\/code>
\n
\nTo start defining directories to watch, you must have a watch block. Each block underneath a watch block is a directory that fsniper monitors for files that are closed.<\/p>\n
\nfsniper can match mime-types, like text\/plain, image\/png, etc. You can use the file utility to figure out the mime-type, use file -ib to get the mime-type that fsniper sees.
\nYou can also have wildcards on each side of the mime-type, so image\/* would match all images, etc.<\/p>\n
\nThe most common pattern would be shell globs, like .txt or .html. This matches any shell like file pattern.<\/p>\n
\nfsniper can be compiled with PCRE support to allow more complicated regular expression matching. Regex patterns are enclosed in forward slashes. Consult the PCRE documentation for the flavor of regular expressions supported. Remember, the entire filename (including path) is matched against the regex.<\/p>\n
\nThe handler scripts do not always have to be custom written. You can use the %% replacement to do some script-like behavior. For example, this handler line:<\/p>\nhandler = tar cvz archive-%%.tar.gz %%<\/code>
\nThis will create a tar\/gz file of the files that match the file pattern.<\/p>\n
\nSince fsniper uses the shell to execute handlers, the shell’s PATH environment variable is respected to find the handlers. fsniper automatically prepends ~\/.config\/fsniper\/scripts into PATH, so it is common to place custom scripts in that directory.<\/p>\n
\n0 : the handler handled this file.<\/p>\n
\nIt is possible that a handler can handle a file, but not at this moment. A common example would be that the handler is supposed to scp a file to a remote server, but that server is currently not available. The handler script returns a 2 to indicate that it can handle it, just not right now. fsniper detects this return code and sleeps for a period of time, then retries the handler.<\/p>\n
\n
\n--help
\nPrints this help text.
\n--version
\nPrints version information.
\n--daemon
\nRun as a daemon.
\n--verbose
\nTurns on debug text.
\n--sync
\nSync mode (for debugging).
\n--log-to-stdout
\nLog to stdout alongside the usual log file.
\n<\/code><\/p>\n