Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

    $ echo foo > /tmp/test
    $ krep -c foo /tmp/test
    Found 4 matches


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


    $ mkfifo .gitignore
    $ rg x


Yeah... because that's totally the same thing. All bugs are created equal! You sure showed me.

    $ mkfifo foo
    $ grep wat foo


[flagged]


Feel free to submit a patch!


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.


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


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.


>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


> 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?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: