Ripgrep: "--null" or "--print0" option?

[gwerbin]

Is there any chance you'd be interested in implementing a feature like Ag's --null option, and Ack's (not to mention find's) --print0 option? If you did, it'd be really easy to make tag work with Ripgrep, not to mention more supportive of machine-parsing in general.

[BurntSushi]

grep has this too. Can we write the specification first? Here's my first attempt:

    Whenever a file name is printed, follow it with a NUL byte.
    This includes printing filenames before matches, and when printing
    a list of matching files such as with --count, --files-with-matches
    and --files.

[kaushalmodi]

I would like to have this option too..

For now, my woraround is to do..

rg foo | tr '\n' '\0'

But hopefully internal support of null-separated output makes this faster.

My actual use case is

rg -g '' --files | tr '\n' '\0' >! proj_file_list.txt

[BurntSushi]

@kaushalmodi Unrelated: your -g '' is I think completely superfluous.

[gwerbin]

@BurntSushi LGreatTM, that's a more detailed spec than any of the other tools mentioned here. But maybe it should be both --print0 and --null. Ag has them aliased to each other, Ack only supports --print0, and Pt and Git Grep _only_ support --null.

[kaushalmodi]

@BurntSushi

Unrelated: your -g '' is I think completely superfluous.

Thanks for letting me know.. I'll switch to rg --files then.

@gwerbin

There's -0 too. So -0 or --null or --print0.

[BurntSushi]

In general, when there's been variation in flag options, I've tried to go with what grep does. I'm not a big fan of lots of aliases for doing the same thing, although I have done it in a few places. For a more niche option like this, I'd rather not increase the number of flags.

[gwerbin]

@BurntSushi good to be consistent. Unfortunately I have absolutely no experience programming in Rust, otherwise I'd just make a PR for proof-of-concept.

@kaushalmodi I avoided -0 because I always thought of that as an _input_ parsing option as per, e.g. xargs.

[emlyn]

Just a nit about the wording of the spec (Whenever a file name is printed, proceed it with a NUL byte). I've not heard "proceed" used in this way before, is it a misspelling of "precede", or does it mean "follow"?

[BurntSushi]

@emlyn "to proceed" is "to come after," so yes, "follow" is right. :-)

Looking at the dictionary, it does feel a little non-standard to me. The flavor isn't quite there. "follow" is probably a better word. I fixed the wording. Thanks!

[gwerbin]

@emlyn Good catch. I definitely thought he meant "precede", which in hindsight wouldn't make sense.

@BurntSushi "proceed" is a motion/action verb, meaning either "to continue" or to physically "go forward."

[BurntSushi]

All set! Will be in the next release, hopefully tonight.