Geniuses at HN don't know how to use grep

-a, --text
Process a binary file as if it were text; this is equivalent to the --binary-files=text option.

--exclude-from=FILE
Skip files whose base name matches any of the file-name globs read from FILE (using wildcard matching as described under --exclude).

--include=GLOB
Search only files whose base name matches GLOB (using wildcard matching as described under --exclude).

-r, --recursive
Read all files under each directory, recursively, following symbolic links only if they are on the command line. Note that if no file operand is given, grep searches the working directory.

Is it really that difficult to use? -a makes GNU grep much faster, -r makes it search recursively, and --exclude*/--include can help with the rest. Plus a bunch of simple aliases can make it work the same way ripgrep works.

Attached: news.ycombinator.com_item_id=32213468.png (913x2445, 521.13K)

Other urls found in this thread:

github.com/rauchg/spot
twitter.com/SFWRedditGifs

okay then why doesn't grep enable those flags by default

From the manpage:
--binary-files=TYPE
...
By default, TYPE is binary.
...
Warning: The -a option might output binary garbage, which can have nasty side effects if the output is a terminal and if the terminal driver interprets some of it as commands. On the other hand, when reading files whose text encodings are unknown, it can be helpful to use -a or to set LC_ALL='C' in the environment, in order to find more matches even if the matches are unsafe for direct display.
[/spoiler]
TL;DR: grep plays safe (but this makes it slow. This implies using ripgrep might even be dangerous.

Which option makes grep 10x faster?

The option to rewrite it in Rust.

Try reading the OP, retard.

None of that will make grep as fast as ripgrep.

Prove it. Protip: you can't. because it's fake news.

this is all you need github.com/rauchg/spot

ripgrep is better and you're a contrarian retard

>Don't use the tools your system gives you!
>You NEED this random tool made by some random pajeet because *I* tell you
>Bawww

why would you want recursive searching when you can pipe find into grep?
>use this non-standard incompatible simple tool for which you need a non-standard toolchain to be compiled, y-you fucking contrarian!!!

Attached: 1564801484765.jpg (450x695, 57.12K)

OP I bet you don't even use that feature yourself, but in case you do post your exlude-from file

BurntSushi is whiter than you, straighter than you and maler than you, gay tranny mutt.

I use -a all the time, and only use --include/--exclude when I need it. greping over the whole dir tree and piping to less is enough for me most of the time.

>you can pipe find into grep
Piping into grep is the most retarded shit newfags do kek.

RMS > *

RMS is literally a Jew, although I consider him a honorary Aryan.

>Piping into grep is the most retarded shit newfags do kek.
Do you mean people should use (g)awk instead?

I just do M-x rgrep
>depends on 50 packages
>takes longer to compile than the kernel

>takes longer to compile than your browser
Seems like the more appropriate comparison these days.

>why would you want recursive searching when you can pipe find into grep?
because then you don't have to deal with find's garbage syntax
captcha: TXXXXJ

>weeb username
>straighter than you
(X) doubt

Looks straight to me.

Attached: 644726016397e8fe0079566b4b821005_360_360.jpg (360x360, 30.96K)

Then don't compile it
>but I have to! Because uh because uhhh because I have to
You chose the longer way, so it's going to be longer. Take some responsibility for your actions for once in your life

>muh compile
You don't need to compile anything

>This implies using ripgrep might even be dangerous.
ripgrep has the same behavior as GNU grep with regards to binaries, so this statement makes no sense.

Same argument applies to windows and linux