fswatch(7)

📦
version 1.17.1 · 2 versions
, in fedora 43

💖 fswatch(7) — Miscellaneous Information Manual 💖

okay bestie, welcome to fswatch(7), straight outta the Miscellaneous Information Manual section. this one's the overview page, and it's giving reference material energy, so let's get into it 🫶

real talk first: this man page is kept for reference but it is not to be considered an authoritative or complete source of information. please, consult the official Info documentation shipped with . — that's the actual ✨source of truth✨, this is more like the vibes-only recap. 💅

✨ NAME ✨

fswatch — ask for notification when the contents of the specified files or directory hierarchies are modified.

like. that's it. that's the whole personality. you point it at stuff, it yells at you when the stuff changes. iconic behavior tbh 🦋

🌸 SYNOPSIS 🌸

fswatch (option)* path+

so: zero or more options, then one or more paths. paths are mandatory, bestie, don't come in here pathless 😭

👑 DESCRIPTION 👑

the fswatch command receives notifications when the contents of the specified files or directories are modified. that's the whole gig, and it does it six different ways, because why have one monitor when you can have a whole roster 🎀

fswatch implements six kind of monitors:

  • a monitor based on the File System Events API of Apple macOS.
  • a monitor based on kqueue, an event notification interface introduces in FreeBSD 4.1 and supported on most *BSD systems (including macOS).
  • a monitor based on the File Events Notification API of the Solaris kernel and its derivatives.
  • a monitor based on inotify, a Linux kernel subsystem that reports file system changes to applications.
  • a monitor based on the ReadDirectoryChangesW Microsoft Windows API.
  • a monitor which periodically stats the file system, saves file modification times in memory and manually calculates changes. (yes she's the one doing it by hand. respect her grind 💀)

and what does it actually write out? fswatch writes a record for each event it receives containing:

  • the timestamp when the event was received (optionally).
  • the path affected by the current event.
  • a space-separated list of event types (see “EVENT TYPES”).

then the important part: fswatch enters an infinite loop and never returns. it's not a "run and finish" girlie, she is committed 💀

when it receives a SIGABRT, SIGINT or SIGTERM signal, fswatch closes the notification streams and exits gracefully returning 0 to the calling process. so you can get out of it, you just have to ask nicely with a signal ✨

the following options are available:

🎀 OPTIONS 🎀

  • -0, --print0 — use the ASCII NUL character (\0) as line separator. since file names can potentially contain any character but NUL, this option assures that the output of fswatch can be safely parsed using NUL as delimiter, such as using xargs -0 and the shell builtin read -d ''. this is the safe one, use it, i'm begging 🙏
  • -1, --one-event — exit fswatch after the first set of events is received. one and done, she's leaving 🦋
  • --batch-marker marker — print a marker at the end of every batch. an optional marker marker can be specified to override its default value NoOp.
  • --event name — filter event with the specified name. this option can be used multiple times, one for each event name that must be included in the output. stack 'em up bestie 💅
  • -e, --exclude regexp — exclude paths matching regexp. multiple exclude filters can be specified using this option multiple times. see “FILTERING PATHS” for further information.
  • -E, --extended — use extended regular expressions.
  • -f, --format-time format — print the event time using the specified format. supported formats are specified by strftime(3).
  • -h, --help — show the help message. the classic 🫶
  • -i, --include regexp — include paths matching regexp. multiple include filters can be specified using this option multiple times. see “FILTERING PATHS” for further information.
  • -I, --insensitive — use case insensitive regular expressions. Foo and foo are the same girl, no cap.
  • -l, --latency latency — set the latency in seconds. the latency is a double value greater than 0.1. smaller values are currently not allowed in order not to compromise the performance of the system. the default latency is 1 second.
so don't try to sneak in 0.05, she will not allow it, and honestly? she's right 💀
  • -L, --follow-links — follow symbolic links.
  • -M, --list-monitors — list the available monitors. window shopping, basically 👑
  • -m, --monitor name — uses the monitor specified by name. the list of currently available monitors can be obtained using the -h option.
  • --no-defer — sets the kFSEventStreamCreateFlagNoDefer flag on macOS FSEvents monitor, which makes the monitor more responsive. this flag is more appropriate for sessions, while the default behaviour is more appropriate for background, daemon or batch processing apps. so like, interactive girlie vs. background girlie, pick your fighter 🌈
  • -n, --numeric — print the numeric value of the event flag, instead of the array of symbolic names. the numeric value of the event flags are system-specific and may vary across different versions of macOS. as a consequence, the use of numeric values is discouraged.
discouraged!! like, technically supported, but you've been warned, bestie 😭
  • -o, --one-per-batch — print a single message with the number of change events. one message, all the tea, condensed ✨
  • -r, --recursive — watch subdirectories recursively. this option may not be supported on all systems.
  • -t, --timestamp — print the event timestamp. the when of it all 🕐
  • -u, --utf-time — print the event time in UTC format. when this option is not specified, the time is printed using the system local time, as defined by localtime(3).
  • -v, --verbose — print verbose output. she's a talker 🗣️
  • --version — print the version of fswatch and exits.
  • -x, --event-flags — prints the event flags.
  • --event-flag-separator separator — print event flags using the specified separator.

and that's where part 1 wraps, but we are NOT done, bestie — there's more page coming, so hold that thought 💜

✨ MONITORS ✨

okay bestie, so fswatch is basically a front-end to system-specific monitors. rn the available monitors are:

  • The FSEvents monitor — a monitor based on the File System Events API of Apple macOS. 🍎
  • The kqueue monitor — a monitor based on kqueue, an event notification interface introduced in FreeBSD 4.1 and supported on most *BSD systems (including macOS). 🐚
  • The inotify monitor — a Linux kernel subsystem that reports file system changes to applications. 🐧
  • The poll monitor — a monitor which periodically stats the file system, saves file modification times in memory and manually calculates file system changes, which can work on any operating system where stat(2) can be used. 🔄

Each monitor has its own strengths, weakness and peculiarities. Although fswatch strives to provide a uniform experience no matter which monitor is used, it is still important for users to know which monitor they are using and to be aware of existing bugs, limitations, corner cases or pathological behaviour. 💅

🍎 The FSEvents Monitor

The FSEvents monitor, available only on Apple macOS, has no known limitations and scales very well with the number of files being observed. In fact, I observed no performance degradation when testing fswatch observing changes on a filesystem of 500 GB over long periods of time. On macOS, this is the default monitor. ✨

🐚 The kqueue Monitor

The kqueue monitor, available on any *BSD system featuring kqueue, requires a file descriptor to be opened for every file being watched. As a result, this monitor scales badly with the number of files being observed and may begin to misbehave as soon as the fswatch process runs out of file descriptors. In this case, fswatch dumps one error on standard error for every file that cannot be opened. Beware that on some systems the maximum number of file descriptors that can be opened by a process is set to a very low value (values as low as 256 are not uncommon), even if the operating system may allow a much larger value. 😭

If you are running out of file descriptors when using this monitor and you cannot reduce the number of observed items, either:

  • Consider raising the number of maximum open file descriptors (check your OS documentation). 📈
  • Consider using another monitor. 🔁

🐧 The inotify Monitor

The inotify monitor, available on Linux since kernel 2.6.13, may suffer a queue overflow if events are generated faster than they are read from the queue. In any case, the application is guaranteed to receive an overflow notification which can be handled to gracefully recover. fswatch currently throws an exception if a queue overflow occurs. Future versions will handle the overflow by emitting proper notifications. However, the odds of observing a queue overflow on a default configured mainstream GNU/Linux distribution is very low. 😌

The inotify API sends events for the direct child elements of a watched directory and it scales pretty well with the number of watched items. For this reason, depending on the number of files to watch, it may sometimes be preferable to watch a common parent directory and filter received events rather than adding a huge number of file watches. 👑

🔄 The Poll Monitor

The poll monitor was added as a fallback mechanisms in the cases where no other monitor could be used, including:

  • Operating system without any sort of file events API. 🚫
  • Situations where the limitations of the available monitors cannot be overcome (i.e.: observing a number of files greater than the available file descriptors on a system using the kqueue monitor). 😵

The poll monitor, available on any platform, only relies on available CPU and memory to perform its task (besides the stat(2) function). The performance of this monitor degrades linearly with the number of files being watched. The authors' experience indicates that fswatch requires approximately 150 MB or RAM memory to observe a hierarchy of 500.000 files with a minimum path length of 32 characters. A common bottleneck of the poll monitor is disk access, since stat()-ing a great number of files may take a huge amount of time. In this case, the latency should be set to a sufficiently large value in order to reduce the performance degradation that may result from frequent disk access. 🐌

🧠 How to Choose a Monitor

fswatch already chooses the "best" monitor for your platform if you do not specify any. However, a specific monitor may be better suited to specific use cases. Please, read the “MONITORS” section to get a description of all the available monitors and their limitations. 📖

Usage recommendations are as follows:

  • On macOS, use only the FSEvents monitor (which is the default behaviour). 🍎
  • On Linux, use the inotify monitor (which is the default behaviour). 🐧
  • If the number of files to observe is sufficiently small, use the kqueue monitor. Beware that on some systems the maximum number of file descriptors that can be opened by a process is set to a very low value (values as low as 256 are not uncommon), even if the operating system may allow a much larger value. In this case, check your OS documentation to raise this limit on either a per process or a system-wide basis. ⚠️
  • If feasible, watch directories instead of watching files. Properly crafting the receiving side of the events to deal with directories may sensibly reduce the monitor resource consumption. 📁
  • If none of the above applies, use the poll monitor. The authors' experience indicates that fswatch requires approximately 150 MB or RAM memory to observe a hierarchy of 500.000 files with a minimum path length of 32 characters. A common bottleneck of the poll monitor is disk access, since stat()-ing a great number of files may take a huge amount of time. In this case, the latency should be set to a sufficiently large value in order to reduce the performance degradation that may result from frequent disk access. 🐢

🔍 FILTERING PATHS

Received events can be filtered by path using regular expressions. Regular expressions can be used to include or exclude matching paths. The user can specify multiple filter expression in any order and the first matching expression wins. 🏆

Other options govern how regular expressions are interpreted:

  • Regular expressions can be extended if option -E is specified. ✨
  • Regular expressions can be case insensitive if option -I is specified. 🔠

🌈 EVENT TYPES

Event flags identify the kind of change a file system object has undergone. Many of them directly map to common file system operations (such as creation, deletion, update, etc.), others are less common (such as attribute modification), and others are monitor and platform specific. 🧬

Currently, fswatch maps monitor-specific event flags to 'global' event flags acting as a sort of 'greatest common denominator' of all the available monitor flags. The following global event flags are available::

  • NoOp — Idle event, optionally issued when no changes were detected. 😴
  • PlatformSpecific — This event maps a platform-specific event that has no corresponding flag. 🛸
  • Created — The object has been created. 🌱
  • Updated — The object has been updated. The kind of update is monitor-dependent. 🔄
  • Removed — The object has been removed. 🗑️
  • Renamed — The object has been renamed. 🏷️
  • OwnerModified — The object’s owner has changed. 👤
  • AttributeModified — An object’s attribute has changed. 🔧
  • MovedFrom — The object has moved from this location to a new location of the same file system. 📦
  • MovedTo — The object has moved from another location in the same file system into this location. 📥
  • IsFile — The object is a regular file. 📄
  • IsDir — The object is a directory. 📁
  • IsSymLink — The object is a symbolic link. 🔗
  • Link — The object link count has changed. 🔢
  • Overflow — The monitor has overflowed. 💥

✨ EXAMPLES ✨

🌸 Basic Usage

okay so the fswatch syntax is literally this, bestie:

$ fswatch [options] [paths] ...

and then fswatch just… prints change events to standard output. iconic behaviour honestly. by default only the affected file name gets printed, but there are SO many options to format that event record, including:

  • the possibility of adding the event timestamp 👀
  • the possibility of adding the event mask in both textual and numerical form

this next one listens for changes in the current directory and delivers events every 5 seconds:

$ fswatch -l 5 .

and this one listens for changes in the current user home directory and /var/log:

$ fswatch ~ /var/log

🫶 Piping fswatch Output to Another Process

very often you don't just wanna receive an event, you wanna react to it, right? and the simplest way to do that is piping fswatch output to another process. but here's the thing — in Unix and Unix-like file systems, file names may potentially contain any character except NUL (\0) and the path separator (/). so fswatch has a special mode of operation for when its output must be piped to another process. when the [-0] option is used, fswatch uses the NUL character as the record separator, which lets literally any other character show up in a path. and this matters because so many commands and shell builtins (like read) split words and lines by default using the characters in $IFS, which by default contains characters that can be present (although rarely) in a file name — and that means a wrong event path gets received and processed. no cap, that's a real bug source.

probably the simplest way to pipe fswatch to another program so you can respond to an event is using xargs:

$ fswatch -0 [opts] [paths] | xargs -0 -n 1 -I {} [command]
  • fswatch -0 will split records using the NUL character.
  • xargs -0 will split records using the NUL character too. this one is required to correctly match impedance with fswatch 💅
  • xargs -n 1 will invoke command every record. if you wanna do it every x records, then use xargs -n x.
  • xargs -I {} will substitute occurrences of {} in command with the parsed argument. if the command you're running doesn't need the event path name, just delete this option. and if you prefer a different replacement string, swap {} for yours.

🦋 Bubbling Events

a very often requested feature is being able to receive a single event "per batch" instead of getting a whole pile of multiple events. this use case is implemented by the [-o, --one-per-batch] option, which tells fswatch to dump a record containing the number of received events, with zero other detail:

$ fswatch -or /path/to/watch
1
10
[...]

this is useful if, for example, you wanna respond to change events in a way which is (or can easily be) path-independent — because you're not receiving any event detail — and you'd rather "bubble" events together to reduce the overhead of the command being executed. a typical case is a directory synchronisation job whenever some files change. so efficient. so slay. 🔥

🎀 Receiving a Single Event

another requested feature is the possibility of receiving a single event and then exiting. this is most useful when existing scripts processing events include the restart logic of fswatch. this use case is implemented by the [-1, --one-event] option:

$ fswatch -1 /path/to/watch
/path/to/watch

💀 Compatibility With fswatch 0.x

so the previous major version of fswatch (v. 0.x) let users run a command whenever a set of changes was detected, with this syntax:

$ fswatch path program

but starting with fswatch v. 1.x, this behaviour is no longer supported. rip to that era, honestly. the rationale behind this decision includes:

  • the old version only allows watching one path.
  • the command to execute was passed as last argument, alongside the path to watch, making it difficult to extend the program functionality to add multiple path support.
  • the old version forks and executes /bin/bash, which is neither portable, nor guaranteed to succeed, nor desirable by users of other shells.
  • no information about the change events is passed to the forked process.

to solve the aforementioned issues and keep fswatch consistent with common UNIX practices, the behaviour has changed, and fswatch now prints event records to the standard output that users can process further by piping the output of fswatch to other programs. glow up fr fr ✨

and to fully support the old use, the [-o, --one-per-batch] option was added in v. 1.3.3. when specified, fswatch will only dump 1 event to standard output, which can be used to trigger another program:

$ fswatch -o path | xargs -n1 program

in this case, program will receive the number of change events as first argument. and if no argument should be passed to program, then this command could be used:

$ fswatch -o path | xargs -n1 -I{} program

⭐ EXIT STATUS ⭐

fswatch may exit with one of the following exit statuses, bestie — write these down:

FSW_OK 0
FSW_ERR_UNKNOWN_ERROR (1 << 0)
FSW_ERR_SESSION_UNKNOWN (1 << 1)
FSW_ERR_MONITOR_ALREADY_EXISTS (1 << 2)
FSW_ERR_MEMORY (1 << 3)
FSW_ERR_UNKNOWN_MONITOR_TYPE (1 << 4)
FSW_ERR_CALLBACK_NOT_SET (1 << 5)
FSW_ERR_PATHS_NOT_SET (1 << 6)
FSW_ERR_UNKNOWN_MONITOR (1 << 7)
FSW_ERR_MISSING_CONTEXT (1 << 8)
FSW_ERR_INVALID_PATH (1 << 9)
FSW_ERR_INVALID_CALLBACK (1 << 10)
FSW_ERR_INVALID_LATENCY (1 << 11)
FSW_ERR_INVALID_REGEX (1 << 12)
FSW_ERR_MONITOR_ALREADY_RUNNING (1 << 13)
FSW_ERR_STALE_MONITOR_THREAD (1 << 14)
FSW_ERR_THREAD_FAULT (1 << 15)
FSW_ERR_UNSUPPORTED_OPERATION (1 << 16)
FSW_ERR_UNKNOWN_VALUE (1 << 17)

👑 DIAGNOSTICS

fswatch exits 0 on success, and >0 if an error occurs. that's it, that's the whole vibe check.

🌈 COMPATIBILITY

fswatch can be built on any system supporting at least one of the available monitors. periodt.

🍓 BUGS

see https://github.com/emcrisostomo/fswatch/issues for open issues, or to create a new one. don't be shy, they wanna hear from you 🫶

bugs can also be submitted to enrico.m.crisostomo@gmail.com.

and that's the whole page, bestie 💖 this manual came from the redhat linux-gnu source, dated July 23, 2025, and it's fswatch(7) — go forth and watch those filesystems, you absolute icon 🌸💅✨

📦 where this page comes from