3 ms·

Single most useful software tool I've ever used, bar none. I installed WSL on my workstation primarily to get grep on my Windows 10 work laptop, as Notepad++'s

Single most useful software tool I've ever used, bar none. I installed WSL on my workstation primarily to get grep on my Windows 10 work laptop, as Notepad++'s equivalent "Search in Files" function is incredibly slow.

saagarjha 6y ago
Yep. I’m sure this being Hacker News someone will suggest ripgrep as being faster and written in Rust, but grep has been there forever and will always be there forever when you need it. So while I might use something else occasionally, being able to use grep is extremely useful.
- yjftsjthsd-h 6y ago
  At least for my uses, rg is drop-in compatible with most other grep versions (if I pass the right flag or two), so I just use whichever is available. On most personal machines that's rg, on work stuff GNU grep, on small systems busybox grep, on BSDs the local grep, etc. But yes, GNU's version is common and good.
  - rurban 6y ago
    Good might be for the eye of the beholder. But in reality it can be made much much faster, and unicode support would also be a good idea. strings are not just ASCII anymore. it uses a very old and outdated substring search algorithm. even ripgrep does not use the state of the art EPSM substring search. extended pattern matching is not jitted. in 2020 there's no excuse for that. it has no switch to skip the most common ignored files, as in ack, ag or rg. it cannot do unorm, thus fails to find some unicode patterns. debian shipped for a while with the unorm patches, but this caused huge performance regressions on UTF-8 locales. a lot of work is still ahead. Eg. it fails to find "Café" in "Café", with different é's.
    - burntsushi 6y ago
      > and unicode support would also be a good idea. strings are not just ASCII anymore. GNU grep does have some Unicode support when using the UTF-8 locale. Things like \b and \w are Unicode-aware, for example. > it uses a very old and outdated substring search algorithm. even ripgrep does not use the state of the art EPSM substring search. Boyer-Moore is still quite serviceable. So is Two-Way. And neither of them require platform specific vector instructions, so there will be a place for them for a while yet. And as for EPSM, I don't know of any place where that's used in practice. I don't even think Hyperscan implements it. It's hard to beat a well place memchr or a simpler prefilter SIMD approach[1]. > extended pattern matching is not jitted. in 2020 there's no excuse for that. It's not the case that a JIT is always faster than a DFA (or a lazy DFA in GNU grep's case). So, umm, yeah, there are plenty of excuses for it. > it cannot do unorm, thus fails to find some unicode patterns. debian shipped for a while with the unorm patches, but this caused huge performance regressions on UTF-8 locales. a lot of work is still ahead. I don't know of any search tool that does Unicode normalization, probably exactly because of the performance overhead. Unicode normalization negates most if not all of the "clever" optimizations used by GNU grep. It would certainly render the choice of substring algorithm or JIT mostly useless, for example. [1] - http://0x80.pl/articles/simd-strfind.html#algorithm-1-generic-simd http://0x80.pl/articles/simd-strfind.html#algorithm-1-generi...
- burntsushi 6y ago
  Well, if the GP used ripgrep, they wouldn't have needed to install WSL or even cygwin first. ripgrep is a native Windows program.
usr1106 6y ago
True, there is no day without calling grep. Often just simple strings, but a least a couple of times a month also with true regexps. When I still was forced to use Windows in the first decade of 2000 and we had a huge codebase in the company I used an indexing tool called Wilbur http://www.redtree.com/wilbur/index.htm http://www.redtree.com/wilbur/index.htm That was incredibly fast. But of course it did not support regexps.
thebruce87m 6y ago
Git Bash that comes with Git is another low overhead way to get grep since you may already need git anyway.

saagarjha 6y ago

Yep. I’m sure this being Hacker News someone will suggest ripgrep as being faster and written in Rust, but grep has been there forever and will always be there forever when you need it. So while I might use something else occasionally, being able to use grep is extremely useful.

yjftsjthsd-h 6y ago
At least for my uses, rg is drop-in compatible with most other grep versions (if I pass the right flag or two), so I just use whichever is available. On most personal machines that's rg, on work stuff GNU grep, on small systems busybox grep, on BSDs the local grep, etc. But yes, GNU's version is common and good.
- rurban 6y ago
  Good might be for the eye of the beholder. But in reality it can be made much much faster, and unicode support would also be a good idea. strings are not just ASCII anymore. it uses a very old and outdated substring search algorithm. even ripgrep does not use the state of the art EPSM substring search. extended pattern matching is not jitted. in 2020 there's no excuse for that. it has no switch to skip the most common ignored files, as in ack, ag or rg. it cannot do unorm, thus fails to find some unicode patterns. debian shipped for a while with the unorm patches, but this caused huge performance regressions on UTF-8 locales. a lot of work is still ahead. Eg. it fails to find "Café" in "Café", with different é's.
  - burntsushi 6y ago
    > and unicode support would also be a good idea. strings are not just ASCII anymore. GNU grep does have some Unicode support when using the UTF-8 locale. Things like \b and \w are Unicode-aware, for example. > it uses a very old and outdated substring search algorithm. even ripgrep does not use the state of the art EPSM substring search. Boyer-Moore is still quite serviceable. So is Two-Way. And neither of them require platform specific vector instructions, so there will be a place for them for a while yet. And as for EPSM, I don't know of any place where that's used in practice. I don't even think Hyperscan implements it. It's hard to beat a well place memchr or a simpler prefilter SIMD approach[1]. > extended pattern matching is not jitted. in 2020 there's no excuse for that. It's not the case that a JIT is always faster than a DFA (or a lazy DFA in GNU grep's case). So, umm, yeah, there are plenty of excuses for it. > it cannot do unorm, thus fails to find some unicode patterns. debian shipped for a while with the unorm patches, but this caused huge performance regressions on UTF-8 locales. a lot of work is still ahead. I don't know of any search tool that does Unicode normalization, probably exactly because of the performance overhead. Unicode normalization negates most if not all of the "clever" optimizations used by GNU grep. It would certainly render the choice of substring algorithm or JIT mostly useless, for example. [1] - http://0x80.pl/articles/simd-strfind.html#algorithm-1-generic-simd http://0x80.pl/articles/simd-strfind.html#algorithm-1-generi...
burntsushi 6y ago
Well, if the GP used ripgrep, they wouldn't have needed to install WSL or even cygwin first. ripgrep is a native Windows program.

usr1106 6y ago

True, there is no day without calling grep. Often just simple strings, but a least a couple of times a month also with true regexps. When I still was forced to use Windows in the first decade of 2000 and we had a huge codebase in the company I used an indexing tool called Wilbur http://www.redtree.com/wilbur/index.htm http://www.redtree.com/wilbur/index.htm That was incredibly fast. But of course it did not support regexps.

thebruce87m 6y ago

Git Bash that comes with Git is another low overhead way to get grep since you may already need git anyway.