SUPER SAIYAN@lemmy.world to memes@lemmy.world · edit-22 days agoI suck at naming anythinglemmy.worldimagemessage-square36fedilinkarrow-up1255
arrow-up1255imageI suck at naming anythinglemmy.worldSUPER SAIYAN@lemmy.world to memes@lemmy.world · edit-22 days agomessage-square36fedilink
minus-squareMonkderVierte@lemmy.ziplinkfedilinkarrow-up1·edit-21 day ago$ time fd -t f locate /usr /usr/bin/fallocate /usr/include/clang/AST/ASTContextAllocate.h /usr/include/qt6/QtQmlCompiler/6.10.0/QtQmlCompiler/private/qresourcerelocater_p.h /usr/include/qt6/QtQml/6.10.0/QtQml/private/qlazilyallocated_p.h /usr/share/doc/libdc1394/html/structfw__cdev__allocate.html ... /usr/share/xml/docbook/xsl-stylesheets-1.79.2-nons/params/htmlhelp.button.locate.xml /usr/lib/ruby/gems/3.4.0/doc/racc-1.8.1/ri/Racc/Grammar/compute_locate-i.ri /usr/lib/ruby/gems/3.4.0/doc/racc-1.8.1/ri/Racc/Sym/locate-i.ri real 0m0.209s user 0m0.283s sys 0m0.663s Cut by me, because of qr size limit. fd is from here. Disk is NVME on PCIe3.
minus-squareBeigeAgenda@lemmy.calinkfedilinkarrow-up5·edit-22 days agoOr like me obliviously spending cycles trawling through everything. find dir/ -iname "*John*Cena*" or grep -rIi "John.*Cena" dir/
minus-squareMonkderVierte@lemmy.ziplinkfedilinkarrow-up1·1 day ago obliviously spending cycles trawling through everything. Once vs. every time the db gets updated. Database for faster file searching is a HDD relict, imo.
minus-squaremarcos@lemmy.worldlinkfedilinkarrow-up3·2 days ago spending cycles trawling through everything Beats spending cycles indexing everything and never search them.
minus-squareSlurpingPus@lemmy.worldlinkfedilinkarrow-up1·2 days agoUse fd and ripgrep at least. It’s not the stone age.
minus-squareBeigeAgenda@lemmy.calinkfedilinkarrow-up1·2 days agoI’m probably using them already if they are aliased to find and grep.
minus-squareSlurpingPus@lemmy.worldlinkfedilinkarrow-up3·1 day agoBtw, while I’m here: you might also want to look into eza, fzf, bat, and maybe delta (or icdiff for side-by-side comparison). I’m pretty conservative regarding replacement for classic utils, but these are worth it.
minus-squareSlurpingPus@lemmy.worldlinkfedilinkarrow-up1·1 day agoThey use different arguments, so unlikely. Though idk if there are wrappers or anything like that. They’re both easier to use and faster, so it’s worth making sure to switch.
minus-squareqjkxbmwvz@startrek.websitelinkfedilinkarrow-up2·2 days ago grep -rIi “John.*Cena” dir/ I have this sort of thing aliased, with some added --include flags to filter file type (e.g., only match source/script files). Super useful!
minus-squareMeron35@lemmy.worldlinkfedilinkarrow-up1·2 days agoplocate is much faster and requires less resources. macOS users should use mdfind instead
And mlocate for Linux.
Cut by me, because of qr size limit. fd is from here. Disk is NVME on PCIe3.
Or like me obliviously spending cycles trawling through everything.
or
Once vs. every time the db gets updated. Database for faster file searching is a HDD relict, imo.
Beats spending cycles indexing everything and never search them.
Use
fdand ripgrep at least. It’s not the stone age.I’m probably using them already if they are aliased to
findandgrep.Btw, while I’m here: you might also want to look into
eza,fzf,bat, and maybedelta(oricdifffor side-by-side comparison). I’m pretty conservative regarding replacement for classic utils, but these are worth it.They use different arguments, so unlikely. Though idk if there are wrappers or anything like that.
They’re both easier to use and faster, so it’s worth making sure to switch.
I have this sort of thing aliased, with some added
--includeflags to filter file type (e.g., only match source/script files). Super useful!plocate is much faster and requires less resources. macOS users should use mdfind instead