A cross-platform file change monitor with multiple backends: Apple OS X File System Events, *BSD kqueue, Solaris/Illumos File Events Notification, Linux inotify, Microsoft Windows and a stat()-based backend.
The string replacement system of xargs has a limit of 255 bytes on BSD, which osx is based on.
Which means that if fswatch is used with xargs on BSD/osx to process the output using string replacement it will fail on files which path+name are over 255 bytes with an error message "{} no such files or directory".
So on operatings sytems that are based on BSD, people that want to use fswatch with xargs to process output should install "findutils" through brew which provides a GNU version of xargs called gxargs which doesn't have this limitation, and use gxargs instead of xargs.
I lost about 2 hours trying to figure out this problem and i bet a lot of other people using BSD based system did as well so it'd be nice if something was added about this in fswatch manual at the "processing output" section.
emcrisostomo
commented
3 years ago
Hello,
The string replacement system of xargs has a limit of 255 bytes on BSD, which osx is based on.
Which means that if fswatch is used with xargs on BSD/osx to process the output using string replacement it will fail on files which path+name are over 255 bytes with an error message "{} no such files or directory".
So on operatings sytems that are based on BSD, people that want to use fswatch with xargs to process output should install "findutils" through brew which provides a GNU version of xargs called gxargs which doesn't have this limitation, and use gxargs instead of xargs.
I lost about 2 hours trying to figure out this problem and i bet a lot of other people using BSD based system did as well so it'd be nice if something was added about this in fswatch manual at the "processing output" section.
Thanks :)