4 ms·

$ mkfifo .gitignore $ rg x

by oguz-ismail 2y ago

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?

4 ms·

$ mkfifo .gitignore $ rg x

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