←back to thread

Show HN: Krep a High-Performance String Search Utility Written in C

(davidesantangelo.github.io)
173 points daviducolo | 10 comments | 11 Mar 25 16:12 UTC | HN request time: 1.379s | source | bottom
Show context
jurschreuder ◴[11 Mar 25 18:54 UTC] No.43335827[source]▶
Finally something not-Rust!
replies(1): >>43336004 #
1. burntsushi ◴[11 Mar 25 19:13 UTC] No.43336004[source]▶

    $ echo foo > /tmp/test
    $ krep -c foo /tmp/test
    Found 4 matches
replies(2): >>43339438 #>>43341206 #
2. oguz-ismail ◴[12 Mar 25 02:43 UTC] No.43339438[source]▶

    $ mkfifo .gitignore
    $ rg x
replies(2): >>43339469 #>>43341077 #
3. burntsushi ◴[12 Mar 25 02:49 UTC] No.43339469[source]▶
Yeah... because that's totally the same thing. All bugs are created equal! You sure showed me.

    $ mkfifo foo
    $ grep wat foo
replies(1): >>43339494 #
4. burntsushi ◴[12 Mar 25 03:14 UTC] No.43339619{4}[source]▶
Feel free to submit a patch!
5. PhilipRoman ◴[12 Mar 25 08:52 UTC] No.43341077[source]▶
tbf this is a really common pitfall and arguably a design mistake in Linux/POSIX, opening files should be a straightforward operation without pitfalls. Even established programs mess this up all the time, see https://github.com/systemd/systemd/issues/30690 and https://github.com/magic-wormhole/magic-wormhole/issues/363
replies(1): >>43344138 #
6. forgotpwd16 ◴[12 Mar 25 09:13 UTC] No.43341206[source]▶
It worked correctly for me, but in my system uses SSE4.2, similar to other commenter that reported[1] that the program works as expected with SSE4.2 acceleration but fails with AVX2.

[1]: https://news.ycombinator.com/item?id=43335424

7. throw-qqqqq ◴[12 Mar 25 10:01 UTC] No.43341486{4}[source]▶
What kind of toxic attitude is this? The author of ripgrep owes you nothing.

If it’s as easy as you imply (“just”), then make a PR.

I hate this entitled attitude towards FOSS.

8. blueflow ◴[12 Mar 25 15:13 UTC] No.43344138{3}[source]▶
This is by design and a obvious implication from the inode structure. Bash, for example, relies on that for process substitution.

On the other side, systemd-tmpfiles used to recurse into '..' when unlinking, wiping your system. So i'm not surprised they didn't get the open() calls right.

replies(1): >>43347365 #
9. PhilipRoman ◴[12 Mar 25 20:31 UTC] No.43347365{4}[source]▶
>obvious implication from the inode structure

I don't quite follow. In fact, at least on Linux, opening a FIFO with O_RDWR (which POSIX leaves undefined) will not block so it can work. IMO blocking for opening as writable can be justified, but I don't see why opening for readonly has to. I'm sure there is some justification for it like SIGFPE or distinguishing empty data from no data, but the result still seems fishy.

>systemd-tmpfiles used to recurse into '..' when unlinking

ok this one is just hilarious

replies(1): >>43347475 #
10. oguz-ismail ◴[12 Mar 25 20:43 UTC] No.43347475{5}[source]▶
> I don't see why opening for readonly has to.

If it didn't you'd have no way of telling if there's anyone at the write end of the pipe. Isn't it obvious?