Hacker News Reader

Comment by waynesonfire | Hacker News Reader

Apparently,

> Print lines by number

is not supported by GNU grep???

  $ grep --version
  grep (GNU grep) 2.25
  $ cat world
  hello
  $ grep -Hn hello world
  world:1:hello

View on HN

"Print lines by number" is a vague thing to say, particularly since the comparison later includes, "Print specific lines by number".

However, the grep -Hn feature is described in this comparison as, "Prefix the line number to matching lines"

One thing that can help people to compare this sort of tool is to pair technical descriptions like command line parameters with the natural language explanation. If tool foo has a feature you're describing as "Prevent cheesecake" then I have no idea if my tool bar can do that, whereas if you say this is -Xqm then I can read the documentation and discover that I call this "disable refrigerated dessert" and it's -VQb so yes, my tool does this too.

I spent some time recently reading the proposals to fix/ extend C++ ranges P2214 - and because this general idea is very common they often discuss Haskell, Rust or even Python. If you're experienced in a language you already know whether it would spell something FlatMap, flat_map, or flatMap but you might not guess that C++ people would call your filter_map by the name transform_maybe, or as a C++ programmer who has barely dipped their toe in Haskell you wouldn't know that Haskell doesn't use the word "transform" in this context and without being told what it's called you won't find the relevant documentation let alone be able to try it for yourself and appreciate what it's for.

The "print lines by number" was there because earlier versions of ack had a `--line=N` feature, where you could say "ack --line=15-18" and print those four lines. I dropped it because it was hardly any better than using sed.

If you've got suggestions on improvements, please submit an issue. I'd love to hear them.

https://github.com/beyondgrep/website/issues

Or "Limit length of output lines"... how about

   $ grep ... | head -n ...

I think this feature comparison misses how grep is supposed to be used. (See also "Pipe output through a pager or other command")

that limits the number of output lines, not the length.

"grep | head" doesn't limit the length of output lines, but "grep | cut" would.

However, ack and ripgrep's default unpiped output is grouped by file, and if you pipe the output, it doesn't do the grouped output.

The idea of "supposed to be used" is also different for ack than it is for grep. ack is specifically less of a general-use tool than grep. It's meant for searching source code. This is also why I have never said that ack is a replacement for grep.

I agree. I use grep in conjunction with find and parallel to achieve a number of features not native to grep that are built-in to these other tools.

I prefer tools designed with does one thing well philosophy. It lets me scale my knowledge. I can solve many problems with find and parallel not supported by these grep clones.

ripgrep degrades just fine to a normal grep tool. And you can use it in `find` pipelines.

> I prefer tools designed with does one thing well

This is pretty unlikely. For example, you probably use a grep tool that will also do recursive directory traversal for you. It probably even has flags for defining filters on that traversal. Why use such a tool when `find` already does recursive directory traversal for you?

You can update the page with pull requests to this repo: https://github.com/beyondgrep/website

Reply on news.ycombinator.com