←back to thread

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

(davidesantangelo.github.io)
173 points daviducolo | 3 comments | 11 Mar 25 16:12 UTC | HN request time: 0.658s | source
Show context
jurschreuder ◴[11 Mar 25 18:54 UTC] No.43335827[source]▶
Finally something not-Rust!
replies(1): >>43336004 #
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 #
oguz-ismail ◴[12 Mar 25 02:43 UTC] No.43339438[source]▶

    $ mkfifo .gitignore
    $ rg x
replies(2): >>43339469 #>>43341077 #
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 #
1. blueflow ◴[12 Mar 25 15:13 UTC] No.43344138[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 #
2. PhilipRoman ◴[12 Mar 25 20:31 UTC] No.43347365[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 #
3. oguz-ismail ◴[12 Mar 25 20:43 UTC] No.43347475[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?