3 ms·
Yep, this is where our regexes start to fall short. Mind opening a github issue for this? We can likely add another option in our "fallback" regex, but it's a f
by xxbondsxx 11y ago
Yep, this is where our regexes start to fall short. Mind opening a github issue for this? We can likely add another option in our "fallback" regex, but it's a fine line to draw between overmatching and undermatching.
For instance, we currently match on "add/remove" output from git status which is less than fortunate. For performance reasons we don't actually go check if each of those files exists (since sometimes you want to pipe hundreds of results into fpp [EDIT: and are using an expandrive or network mount])
- ploxiln 11y ago[pierce@plo-pro team15]$ time (find . -print0 | xargs -0 stat -f '%N' | wc -l) 4901 real 0m0.079s user 0m0.043s sys 0m0.060s
- xxbondsxx 11y ago@ploxiln -- edited my comment explaining a lot of devs here use network mounts (in which case checking for existence takes a lot longer). I'd love to explore this though, either behind a config setting or eventually as the default behavior! What do you think?
- sandyarmstrong 11y agoI think to have usable matching you're going to have to go that way, unless you want to write custom parsing code for each command's output.
- ploxiln 11y agoyeah, if the files are not either local or on an NFS mount with sub-millisecond latency (my test took ~ 1 second over NFS to a VM), it's going to take too long. I hadn't thought of that situation
- jankassens 11y agoYou could test for a single file (possible with a timeout) and see if it's "fast enough" to check all files. You could also check in the background and update the display if the heuristic turned out wrong.