From 555beb9fd9acf913822d3a079f5c9900a9de9160 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Sun, 19 Apr 2026 12:48:05 +0000 Subject: [PATCH] v0.5.1: search_files uses find -L for macOS symlink start paths MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit BSD find on macOS silently emits nothing when the starting path is itself a symlink (no trailing slash, no -L). On riemann with Homebrew, /usr/local/share/lua is a symlink to /usr/local/Cellar/luarocks/.../share/lua which tripped this — search_files returned empty for clearly-matching patterns. GNU find on Linux follows the starting arg by default, so the bug was invisible on every other host. Add -L explicitly. Both BSD and GNU find accept it, both detect cycles, and behavior becomes consistent. Fixes marfrit-tracker task #16 (opened 2026-04-18 while stress-testing riemann-tools MCP). Co-Authored-By: Claude Opus 4.7 (1M context) --- server.lua | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/server.lua b/server.lua index c2c4b18..2eddf7d 100644 --- a/server.lua +++ b/server.lua @@ -272,7 +272,10 @@ server:tool("search_files", "Search for files by pattern.", { if WINDOWS then return run('dir /b /s "' .. path .. '\\' .. a.pattern .. '"', 30) else - return run("find '" .. path:gsub("'", "'\\''") .. "' -name '" .. a.pattern:gsub("'", "'\\''") .. "' 2>/dev/null", 30) + -- -L: follow symlinks on the start path. macOS BSD find otherwise + -- silently emits nothing when the start path is itself a symlink + -- (common on Homebrew, e.g. /usr/local/share/lua -> Cellar/…/share/lua). + return run("find -L '" .. path:gsub("'", "'\\''") .. "' -name '" .. a.pattern:gsub("'", "'\\''") .. "' 2>/dev/null", 30) end end)