5 ms·

Finally something not-Rust!

by jurschreuder 2y ago

burntsushi 2y ago
$ echo foo > /tmp/test $ krep -c foo /tmp/test Found 4 matches
- oguz-ismail 2y ago
  $ mkfifo .gitignore $ rg x
  - burntsushi 2y ago
    Yeah... because that's totally the same thing. All bugs are created equal! You sure showed me. $ mkfifo foo $ grep wat foo
    - oguz-ismail 2y ago
      [flagged]
      - burntsushi 2y ago
        Feel free to submit a patch!
      - throw-qqqqq 2y ago
        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.
  - PhilipRoman 2y ago
    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 https://github.com/systemd/systemd/issues/30690 and https://github.com/magic-wormhole/magic-wormhole/issues/363 https://github.com/magic-wormhole/magic-wormhole/issues/363
    - blueflow 2y ago
      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.
      - PhilipRoman 2y ago
        >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
        oguz-ismail 2y ago
        > 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?
- forgotpwd16 2y ago
  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 https://news.ycombinator.com/item?id=43335424

Finally something not-Rust!

burntsushi 2y ago

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

oguz-ismail 2y ago
$ mkfifo .gitignore $ rg x
- burntsushi 2y ago
  Yeah... because that's totally the same thing. All bugs are created equal! You sure showed me. $ mkfifo foo $ grep wat foo
  - oguz-ismail 2y ago
    [flagged]
    - burntsushi 2y ago
      Feel free to submit a patch!
    - throw-qqqqq 2y ago
      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.
- PhilipRoman 2y ago
  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 https://github.com/systemd/systemd/issues/30690 and https://github.com/magic-wormhole/magic-wormhole/issues/363 https://github.com/magic-wormhole/magic-wormhole/issues/363
  - blueflow 2y ago
    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.
    - PhilipRoman 2y ago
      >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
      - oguz-ismail 2y ago
        > 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?
forgotpwd16 2y ago
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 https://news.ycombinator.com/item?id=43335424